[Cython] Git workflow, branches, pull requests

[mark florisson]

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
> _______________________________________________
> cython-devel mailing list
> cython-devel at python.org
> http://mail.python.org/mailman/listinfo/cython-devel
>

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.