[gdal-dev] [update] Re: Travis CI continuous integration service for GDAL

[Antonio Valentino]

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