[Python-Dev] Hg: inter-branch workflow
Reid Kleckner
reid.kleckner at gmail.com
Thu Mar 17 15:03:36 CET 2011
On Thu, Mar 17, 2011 at 9:33 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Thu, 17 Mar 2011 09:24:26 -0400
> "R. David Murray" <rdmurray at bitdance.com> wrote:
>>
>> It would be great if rebase did work with share, that would make a
>> push race basically a non-issue for me.
>
> rebase as well as strip destroy some history, meaning some of your
> shared clones may end up having their working copy based on a
> non-existent changeset. I'm not sure why rebase would be worse that
> strip in that regard, though.
I don't think anyone has laid out why destroying history is considered
bad by some, so I thought I'd plug this post:
http://paul.stadig.name/2010/12/thou-shalt-not-lie-git-rebase-ammend.html
Essentially, lets say I have a handful of commits hacking on C code.
While I wrote them, someone changed a C API from under me and pushed
their change. However, in the last change, I remove my dependence on
this API. I pull, rebase, rebuild and test. The tests pass in the
latest commit, so I push. But now if someone tries to go back to
those intermediate commits (say, searching for the introduction of a
regression), they will find a broken build.
It boils down to when you alter history, at each altered commit you
have some source tree state for which you haven't built and run the
tests.
On the flipside, in the case of a single commit, it's easy to pull,
rebase, rerun tests, and then push. Running the tests takes a while
so you open yourself to another push race, though.
98% of the time, if you don't actually have merge conflicts, applying
your change over someone else's without testing will work, so I feel
like rebasing a single commit without testing is no big deal. On the
off chance that it breaks, the buildbots will find out. Just don't
rebase a whole feature branch of commits, leave the final merge in.
Reid
More information about the Python-Dev
mailing list