[Cython] Git workflow, branches, pull requests

[Dag Sverre Seljebotn]

On 05/06/2011 09:24 AM, Vitja Makarov wrote:
> 2011/5/6 Dag Sverre Seljebotn<d.s.seljebotn at astro.uio.no>:
>> 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
>>
>
>
> Right.
>
>> 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.)
>>
>
> Thank you for explanation.
>
> So btw, when I do rebase and my changes were already pushed I have to
> use forced push.
> Is forced push ok?

Forced push is trivially OK if the commits you are "overwriting" has not 
been fetched anywhere else (or, you plan to immediately erase them at 
their other location). Otherwise, you really need to pay attention.

In general, if you make the following cycle "atomic", you're OK:

  - Fetch branch from github
  - Make some commits
  - Force-push back to github

However, if you interrupt the cycle in the middle, you'll need to spend 
time to recover from your "race" :-)

Here's a similar question which lists some convenient commands:

http://stackoverflow.com/questions/3815193/how-can-i-safely-use-git-rebase-when-working-on-multiple-computers

(Although I'm not sure if I recommend getting into the habit of doing 
"git push -f", just typing "git push -f origin mybranch" seems a lot safer.)

Dag Sverre