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

[Even Rouault]

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
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
git svn dcommit --dry-run # just to be sure
git show first_hash..last_hash # just to be sure
git svn dcommit

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.

> reviewer can either push commits to that repos, or add commits after
> pulling the contributor's code.
> 
> What you would look for is called "interactive rebasing"
> 
> You can "squash" history in a single commit doing git rebase -i
> <hash>, which will open an editor with the commits since <hash>, you
> then mark all commits except one as "squash"..
> History will then contain a single commit, but it will not let you
> push back to the same branch (unless you do a force push, which messes
> with the history)
> 
> So the sequence would be:
> 
> git pull <some repos> <some branch>
> git rebase -i <hash>
> <mark commits as "squash">
> git push origin master
> 
> But this removes the commits from the original authore, so to keep
> history you would do
> 
> git pull <some repos> <some branch>
> git push origin master
> 
> >> I even did some collaborative work last year in gdal using github as
> >> the shared repos, and pushing to svn but that was a bit clumsy (the
> >> git-svn part) and I have stopped using that approach.
> > 
> > you mean "git svn dcommit" didn't work as you expected ?
> 
> it's a little unwieldy, but seems to work as expected. I was always
> nervous to do something wrong - because a svn commit / svn dcommit
> cannot be reversed, unlike git commit (until you push),
> so I was always doing a dry-run commit, examine the diffs, and then do
> a real dcommit.
> 
> But it does work, as long as you're careful.  It's just a bit more
> involved than working with git or svn alone.
> 
> >> > But as a SVN committer, my opinion is obviously biased since
> >> > contributing is of course more straighforward than for a non-GDAL
> >> > committer. GIT has certainly a more egalitarian approach (everyone
> >> > can commit or fork), although that someone that hasn't push rights
> >> > can only send pull requests to the main repository.
> >> 
> >> I'd say svn is fine for core devs, not optimal for occasional
> >> submitters.
> >> 
> >> > My knowledge of GIT is rather limited, but, for a GDAL contributor
> >> > without commit (SVN)/push(GIT) rights to the main repository, what
> >> > improvements would a full move to GIT would offer with respect to the
> >> > current git-svn mirroring ?
> >> 
> >> a more seamless flow between the dev's work and pushes to the main
> >> source.
> >> 
> >> As far as I can tell, the git part of your setup is just for the
> >> continuous builds right?
> > 
> > Yes mostly, and because it might be more convenient for people prefering
> > GIT to do work. This could also be a kind of cheap test bench to assess
> > what switching to GIT could bring to GDAL.
> > 
> >> In fact git is used as a read-only, so I
> >> don't see how having a git mirror helps contributing code.
> > 
> > Can't people fork the git mirror ? My hope was that a GDAL SVN committer
> > could use its own git-svn mirror, that has a origin to OSGeo/gdal, and
> > try to merge in it pull requests submitted to OSGeo/gdal, and then git
> > svn dcommit. I thought this was possible, but I might be wrong. I'm
> > aware that git-svn would be more complicated than a pure GIT repository.
> > But, from the side of occasional contributors, would that make a
> > difference in their process ?
> > 
> > I'm trying to understand if the git-svn mirror can bring some factual
> > evidence that a switch to GIT would be beneficial.
> 
> Now I understand better your intent - you would use the git mirror to
> be able to have people work on using git/github, and then svn as the
> "central" code base that core devs would commit to.
> 
> For occasional contributors, it would probably be easier. For the code
> managers / core devs, it means an extra step in merging the code to
> svn trunk, and entails learning another (git) versioning tool, as well
> as the git/svn bridge.
> Although once setup, it's not that hard.
> 
> It would certainly be easier, especially in the short-term, to keep
> svn and allow to use git for contributors. Maybe eventually switch to
> git entirely if it seems like the right choice.
> 
> I personally prefer git to do testing and work on different branches,
> because of git's context-switching features.  You do a "git checkout
> somebranch" and all code moves to that branch, in a few seconds.
> It works fine as long as you commit or stash your changes.
> 
> BTW there are some good notes on the git/svn bridge at
> http://trac.osgeo.org/gdal/wiki/UsingGitToMaintainGDALWorkflow
> but you probably already consulted that.
> 
> cheers
> Etienne
> 
> > Even