[Cython] Git workflow, branches, pull requests

[Dag Sverre Seljebotn]

On 05/05/2011 10:09 PM, mark florisson wrote:
> On 5 May 2011 21:52, Dag Sverre Seljebotn<d.s.seljebotn at astro.uio.no>  wrote:
>> There was just a messup in git history: Mark's OpenMP pull request got
>> merged twice; all commits show up two times.
>>
>> It doesn't matter, since the two openmp branches with the same changes
>> merged OK, but we shouldn't make this a habit. For instance, the openMP
>> commits also show up as part of vitja's pull request, which is confusing.
>>
>> In Mercurial speak: The openmp branch was used like you would use a
>> Mercurial "patch queue" in one case, and as a branch in another case. In git
>> they are the same technically and you rely on conventions to make sure you
>> don't treat a "queue" as a "branch".
>>
>> OPTION A) Either i) only branch from master, or ii) make sure you agree with
>> whoever you're branching from that this is a "branch", not a "patch queue",
>> so that it isn't rebased under your feet.
>>
>> We could also, say, prepend all patch queues with an underscore (its
>> private).
>>
>> OPTION B) Stop rebasing. I'd have a very hard time doing that myself, but
>> nobody are pulling from dagss/cython these days anyway.
>>
>> Opinions?
>>
>> FYI,
>>
>> The workflow me and Mark is currently using is:
>>
>>   a) Fork off a feature branch from master (with master I'll always refer to
>> cython/master)
>>
>>   b) When one gets in sync with master, do NOT merge master, but rather
>> rebase on top of it:
>>
>>      git pull --rebase origin master
>>
>>   c) Continue rebasing, and eventually .
>>
>> The advantage of this approach is that ugly merges disappear from history,
>> since commits are rewritten. And the history graph looks very nice and is
>> easy to follow.
>>
>> BUT, if the result is duplication, we should avoid this practice, and rather
>> always merge.
>>
>>
>> Dag Sverre
 >
> I think the rebasing is pretty elegant, so I'm +1 on that, as long as
> everyone agrees because those duplicated commits are nasty. I'm
> surprised git didn't issue an error to prevent this.

Going OT:

I guess a principle of git is to be as dumb as possible, so that you can 
predict what it does.

When you rebase, you really get entirely new versions of all your 
commits. There's no way to link the old commits with the new commits, 
except to compare the commit message. And not even that, since you can 
change commit messages during rebases.

Git doesn't even store commits by their diff, it stores each commit by 
the resulting full tree contents, so even if the patch is the exact 
same, git couldn't really know (without going through your entire 
history and check for "similar changes"...ugh)

What I wish they did was to add a simple "rebased-from" header field on 
commits, which could be trivially checked on merges to issue a warning. 
I guess the reason it is not there is because usually you're about to 
(automatically) throw away the commits, so the only purpose it would 
have would be sort of pedagogical.

Dag Sverre