Hi Even,
Il 14/10/2012 11:54, Even Rouault ha scritto:
Hi Antonio,
I suppose that at this point you already used
git remote add <NAME> <URL>
git fetch <NAME>
In the context I described, would be NAME = nas-fixes and URL =
https://github.com/jef-n/gdal ?
yes
Well, I don't remember having used that. Apparently just "git pull
https://github.com/jef-n/gdal nas-fixes" did the trick.
ah, sorry, misunderstanding on my part.
>> git checkout trunk
>> git svn rebase
>> git checkout -b nas-fixes
this creates a new branch named nas-fixes from master (trunk) and then
checkout it.
then you do
>> git pull https://github.com/jef-n/gdal nas-fixes
Unless you are 100% sure that the remote nas-fixes branch started from
the current HEAD in master the above pull will perform a merge with the
possibility of conflicts.
In this cases I use to do
git checkout trunk
git svn rebase
git remote add jef-n https://github.com/jef-n/gdal
git fetch jef-n
git checkout -b nas-fixes jef-n/nas-fixes
in this way you will never get any conflict at this point and you can
address all issues during the rebase
>> git rebase -i trunk
After all, I suppose it doesn't makes much difference.
someone [1] at this point suggests to use
git merge --no-ff nas-fixes
in order to keep track of the existence of the merged branch.
It is particularly useful if you use git-rebase before merging.
[1] http://nvie.com/posts/a-successful-git-branching-model/
I'm not sure if -no-ff or -ff makes a difference in the context of a git svn
repository. Once you dcommit to SVN, anything related to GIT branches will be
lost, and the merge commit itself would certainly not be SVN dcommit'ed (I
think).
Best regards,
Even
best regards
--
Antonio Valentino
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
