[Cython] Git workflow, branches, pull requests

[Vitja Makarov]

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?

-- 
vitja.