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 >> ________________________________ >> cython-devel mailing list cython-devel@python.org >> http://mail.python.org/mailman/listinfo/cython-devel > > _______________________________________________ > cython-devel mailing list > cython-devel@python.org > http://mail.python.org/mailman/listinfo/cython-devel > > _______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel