[Cython] Git workflow, branches, pull requests

[Robert Bradshaw]

On Thu, May 5, 2011 at 1:22 PM, Stefan Behnel <stefan_ml at behnel.de> wrote:
> Dag Sverre Seljebotn, 05.05.2011 21:52:
>>
>> There was just a messup in git history: Mark's OpenMP pull request got
>> merged twice; all commits show up two times.
>
> What (I think) happened, was that Vitja pulled in Mark's changes into his
> unreachable code removal branch, and they ended up in his pull request. I
> guess I was assuming that git wouldn't care too much about branch
> duplication, so I just accepted the pull request via the web interface.
> Apparently, it did care.
>
> I tend to rebase my local change sets before pushing them, and I think it
> makes sense to continue doing that.

+1, I think for as-yet-unpublished changes, it makes the most sense to
rebase, but for a longer-term branch, merging isn't as disruptive to
the history (in fact is probably more reflective of what's going on)
and is much better than duplication.

To clarify, is this only a problem when we have

A cloned from master
B cloned from A (or from master and then pulls in A)
A rebases
A+B merged into master

? If this is the case, then we could simply make the rule that you
should ask before hacking a clone atop anything but master. (Multiple
people can share a repeatedly-rebased branch, right.) We could also us
the underscore (or another) convention to mean "this branch is being
used as a queue, puller beware."

Surely other projects have dealt with this.

- Robert