[Cython] Git workflow, branches, pull requests

[Dag Sverre Seljebotn]

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