RFC: dealing with dead, anonymous feature branches

Martin Geisler mg at lazybytes.net
Wed May 19 17:53:34 CDT 2010


Gilles Moris <gilles.moris at free.fr> writes:

> On Friday 07 May 2010 07:34:23 pm Martin Geisler wrote:
>
>> One of the very first times I talked about Mercurial here in Zurich,
>> I was asked what one should do if a set of changesets turned out to
>> be useless -- an abandoned feature branch. When I say "branch" in the
>> following, I'm not talking about named branches, I'm just talking
>> about topological branches, named or not.
>
> As I understand, the original problem is that we need to push -f
> because those abandoned branches can create remote head. So the
> solution can be to avoid sending those heads, but we could also relax
> the push logic and allow them to be pushed.
>
> Notwithstanding the fact that we really don't want them to be pushed,
> they won't create much trouble remotely *with a recent mercurial
> version*. They won't clutter on merge, update or heads display.
> Allowing to push closed heads would be in line with all the other
> adjustment made for merge, update and heads, and probably easier to
> implement in the 1.6 timeframe. And there would be no more problems on
> push.
>
> I know that this is the opposite direction than the original
> proposition, but could it be the first step to, at least, solve the
> workflow issue ?

I think it would -- when I told people that they cannot really get rid
of their abandoned changesets, they asked me if they should then close
the branch (they meant topological branch). I had to answer something
like "well, yeah... that would work if it was a *named* branch...".

I still see some interesting uses for the idea of excluding some
changesets from push/pull: Now that people are mad about 'hg qdelete'
actually deleting stuff, then it would be nice to simply leave the
changesets behind but mark them as dead so that they wont be pushed.

The same tool would allow us to implement 'hg commit --ammend' by
marking the current tip as dead and making a new commit that
incorporates the changes along with the changes in the old tip. Like
this:

  hg diff > tmp
  hg revert --all
  hg commit --mark-dead -m 'Killed by commit --ammend.'
  hg update -r -3
  hg export -r -2 | hg import --no-commit -
  hg import --no-commit tmp
  rm tmp

where I assumed that things are nicely linear so that -3 and -2 refer to
the parent and grandparent changesets.

-- 
Martin Geisler

Fast and powerful revision control: http://mercurial.selenic.com/
-------------- 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-devel/attachments/20100520/8d57504e/attachment.pgp>


More information about the Mercurial-devel mailing list