[Cython] Git workflow, branches, pull requests

[Dag Sverre Seljebotn]

On 05/06/2011 08:20 AM, Vitja Makarov wrote:
> 2011/5/6 Robert Bradshaw<robertwb at math.washington.edu>:
>> I don't like the default to be "don't pull from me"--I'd rather there
>> be some convention to indicate a branch is being used as a queue.
>> Maybe even foo-queue, or a leading underscore if people like that.
>>
>> On Thu, May 5, 2011 at 2:03 PM, Dag Sverre Seljebotn
>> <d.s.seljebotn at astro.uio.no>  wrote:
>>> Yes, that is the only time it happens.
>>>
>>> Do we agree on a) ask before you pull anything that is not in cython/* (ie
>>> in private repos), b) document it in hackerguide?
>>>
>>> DS
>>>
>>>
>>> --
>>> Sent from my Android phone with K-9 Mail. Please excuse my brevity.
>>>
>>> Robert Bradshaw<robertwb at math.washington.edu>  wrote:
>>>>
>>>> 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
>
>
> About my branch:
>
> I've rebased it from upstream/master at home and made "forced push"
> At work I pulled it back and rebased from origin, then I tried to
> rebase if again from upstream/master

Do I understand correctly that you:

  a) You make local changes at home
  b) Rebase them on cython/master
  c) Force-push to vitja/somebranch
  d) Go to work, where you have other local changes
  e) Rebase your work changes at work on top of vitja/somebranch

If this is correct; then this can't work. The reason is that after the 
force-push in c), there are no shared commits (apart from what's shared 
from cython/master) between your work computer and vitja/somebranch.

So the rule is: If you rebase a branch, then if you have other copies of 
that branch (like on a work computer), destroy them (e.g., git branch 
-D)!  And then fetch new copies of the branches.

(And as you say, if you do have different changes in many places then 
you can recover from an unfortunate rebase by cherry-picking. And you 
can always undo a rebase by looking at "git reflog" and manually check 
out the old HEAD.)

Dag Sverre