Re: [Cython] Git workflow, branches, pull requests
Hi, On Thu, May 5, 2011 at 12:52 PM, Dag Sverre Seljebotn wrote: > There was just a messup in git history: Mark's OpenMP pull request got > merged twice; all commits show up two times. > > It doesn't matter, since the two openmp branches with the same changes > merged OK, but we shouldn't make this a habit. For instance, the openMP > commits also show up as part of vitja's pull request, which is confusing. > > In Mercurial speak: The openmp branch was used like you would use a > Mercurial "patch queue" in one case, and as a branch in another case. In git > they are the same technically and you rely on conventions to make sure you > don't treat a "queue" as a "branch". > > OPTION A) Either i) only branch from master, or ii) make sure you agree with > whoever you're branching from that this is a "branch", not a "patch queue", > so that it isn't rebased under your feet. > > We could also, say, prepend all patch queues with an underscore (its > private). > > OPTION B) Stop rebasing. I'd have a very hard time doing that myself, but > nobody are pulling from dagss/cython these days anyway. What about: OPTION C) The one who pushes things into the master knows master enough to see whether or not it makes sense to merge this, or if it was already in, he/she will simply comment into the pull request and close it manually Ondrej ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Git workflow, branches, pull requests
On 05/13/2011 12:36 AM, Ondrej Certik wrote: Hi, On Thu, May 5, 2011 at 12:52 PM, Dag Sverre Seljebotn wrote: There was just a messup in git history: Mark's OpenMP pull request got merged twice; all commits show up two times. It doesn't matter, since the two openmp branches with the same changes merged OK, but we shouldn't make this a habit. For instance, the openMP commits also show up as part of vitja's pull request, which is confusing. In Mercurial speak: The openmp branch was used like you would use a Mercurial "patch queue" in one case, and as a branch in another case. In git they are the same technically and you rely on conventions to make sure you don't treat a "queue" as a "branch". OPTION A) Either i) only branch from master, or ii) make sure you agree with whoever you're branching from that this is a "branch", not a "patch queue", so that it isn't rebased under your feet. We could also, say, prepend all patch queues with an underscore (its private). OPTION B) Stop rebasing. I'd have a very hard time doing that myself, but nobody are pulling from dagss/cython these days anyway. What about: OPTION C) The one who pushes things into the master knows master enough to see whether or not it makes sense to merge this, or if it was already in, he/she will simply comment into the pull request and close it manually This doesn't make sense to me. Are you sure you read the scenario correctly? Dag Sverre ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
