2011/5/6 Dag Sverre Seljebotn <d.s.seljeb...@astro.uio.no>: > On 05/06/2011 08:20 AM, Vitja Makarov wrote: >> >> 2011/5/6 Robert Bradshaw<rober...@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.seljeb...@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<rober...@math.washington.edu> wrote: >>>>> >>>>> On Thu, May 5, 2011 at 1:22 PM, Stefan Behnel<stefan...@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. _______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
