Closed branch push behavior?

Martin Geisler mg at lazybytes.net
Tue Dec 6 15:59:07 CST 2011


Angel Ezquerra <angel.ezquerra at gmail.com> writes:

> El 06/12/2011 18:41, "Matt Mackall" <mpm at selenic.com> escribió:
>> >
>> > Matt,
>> >
>> > I have a related question that hopefully you can also address.
>> >
>> > I wonder whether it makes sense for mercurial to complain that
>> > you'll create a new head when you close a branch and push the
>> > resulting new head.
>> >
>> > Technically mercurial is right in that you are indeed pushing a new
>> > head, but isn't it obvious that this new head is not meant to be
>> > developed further?
>>
>> Sure, but that's not what push cares about here. Push cares about
>> whether or not the history should be transmitted. If, for instance,
>> you're Chuck's coworker, the answer here is a big fat "no": you
>> shouldn't have created the branch in the first place and now this
>> warning is your last chance to avoid publishing it.

Right, it's the last chance before publication. But since we have an
append-only history in Mercurial, wouldn't it make more sense to let him
fix the mistake by closing the branch again?

Now we require him to "somehow" (using mq, transplant, or other advanced
commands) to redo the commits.

Fixing the mistake by closing the branch is much more in line with how
we recommend fixing other mistakes with 'hg backout'.

Here's a quick idea: could we let

  hg branch --rename default

add a changeset that

1) closes the current branch

2) makes "default" the current branch

3) says "please treat the ancestor changesets as if they were on the
   default branch" too

While I do history mutation all the time myself, I do actually like the
idea of embedding these markers in the append-only history to make a
smart Mercurial client act as if the history is mutated.

In some sense, it's similar to how tags work -- you can move a tag
around and even delete it, and you do so with more append-only history
that is spread as needed with pulls.

> I don't get this. If I were Chuck's coworker and I tried to push a new
> branch I should get the usual "Push creates new branch, use
> --new-branch flag" message, regardless of whether I had closed the
> branch or not. If on the other hand the branch were on the server
> already, mercurial making it hard for me to close the branch would not
> change the fact that the branch would be on the server already :-)
>
> That being said closing branches would be much more useful if closed
> branches were not pushed or pulled buy default. For instance it would
> let you stop mistakes from being propagated as in Chuck's scenario.

That's close to the dead branches concept Henrik and I played around
with. I'm afraid the patch queue hasn't been updated in ages:

  https://bitbucket.org/mg/dead-branches

-- 
Martin Geisler

Mercurial links: http://mercurial.ch/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://selenic.com/pipermail/mercurial/attachments/20111206/43e7866d/attachment.pgp>


More information about the Mercurial mailing list