On Thu, May 5, 2011 at 1:22 PM, Stefan Behnel <stefan_ml@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