Hi
On Wed, Oct 10, 2012 at 5:55 PM, Even Rouault
<even.roua...@mines-paris.org> wrote:
> Le mercredi 10 octobre 2012 21:49:49, Etienne Tourigny a écrit :
>> Hi Even,
>>
>> the main advantage of github is that you can manage patches/pull
>> requests more easily, and it's easy for someone to setup a fork with
>> substantial changes, and anyone can pull that fork and try it without
>> much hassle.
>> The other way of doing it with trac/svn is to upload patches to
>> tickets, and then more patches after review etc.... Which works fine,
>> but a bit clumsy compared to github forks and pull requests.
>
> If someone submits a pull requests, and if that submitted code needs to be
> changed due to what is seen during the review, what is the process ? It is
> certainly nice to be able to merge the history of commits (I often wish that
> submitted patches to Trac would be split into more logical smaller changesets
> to make review easier). But that only makes sense when the history is clean
> (you generally don't care about trial-and-errors intermediate commits that
> would pollute the history of the main repository). I believe that it is
> possible to do that with git ("git rewrite history" leads to http://git-
> scm.com/book/ch6-4.html), but to my non-git specialists eyes, this looks far
> from being obvious. Do you know how QGIS for example deal with that ?
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
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
