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

[Etienne Tourigny]

Hi

On Sun, Oct 14, 2012 at 7:49 AM, Antonio Valentino
<antonio.valentino at tiscali.it> wrote:
> 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.


In fact, normally just a git pull <repos> <branch> (like Even did)
takes care of all the complexities

Also, checking out into a new branch is also not entirely important,
you can do it from the master branch. The end result will be the same,
with less steps.
But it's more methodical to do it like Even did.

cheers
Etienne

>
>
>>> 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 at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev