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

[Antonio Valentino]

Hi Even,

Il giorno 14/ott/2012, alle ore 01:02, Even Rouault <even.rouault at mines-paris.org> ha scritto:

> Just a quick follow-up.
> 
> I've just received the first pull request ( 
> https://github.com/OSGeo/gdal/pull/1 ) and managed to merge it and commit it 
> to SVN with the following (based on your below advice) :
> 
> git checkout trunk
> git svn rebase
> git checkout -b nas-fixes

I suppose that at this point you already used

git remote add <NAME> <URL>
git fetch <NAME>

> git pull https://github.com/jef-n/gdal nas-fixes
> git rebase -i trunk  # here I've "merged" a few commits into single ones (for 
> commits that fixed previous commits)
> 
> # compile, test, etc...
> 
> git checkout trunk
> git merge nas-fixes

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/

> git svn dcommit --dry-run # just to be sure
> git show first_hash..last_hash # just to be sure
> git svn dcommit
> 

yes, the procedure you described works in general, not only for pull requests or for projects hosted on GitHub :)

Any public or private git branch that you can access can be merged using the above procedure


> The only annoying (but logical) thing is that I appear as the committer of the 
> changes, instead of the original author. Perhaps there would be an automated 
> way of adding the original git commiter name in the SVN commit message to keep 
> proper attribution.
> 
> An interesting thing with Travis is that it also builds the pull requests, so, 
> even before looking at the code, it is easy to check if a pull request isn't 
> too broken.

nice ;)

--
Antonio Valentino