atom feed69 messages in com.selenic.mercurial-develRe: RFC: dealing with dead, anonymous...
FromSent OnAttachments
Martin GeislerMay 7, 2010 10:33 am 
Dirkjan OchtmanMay 7, 2010 10:37 am 
Matt MackallMay 7, 2010 10:59 am 
Martin GeislerMay 7, 2010 11:14 am 
Matt MackallMay 7, 2010 11:46 am 
Dirkjan OchtmanMay 7, 2010 1:14 pm 
Gilles MorisMay 8, 2010 12:10 am 
Martin GeislerMay 8, 2010 1:31 am 
Martin GeislerMay 8, 2010 1:34 am 
Martin GeislerMay 8, 2010 1:48 am 
Martin GeislerMay 8, 2010 2:09 am 
Gilles MorisMay 8, 2010 3:50 am 
Martin GeislerMay 8, 2010 1:10 pm 
Gilles MorisMay 9, 2010 9:33 am 
Gilles MorisMay 9, 2010 1:49 pm 
Gilles MorisMay 9, 2010 1:49 pm 
Gilles MorisMay 9, 2010 1:49 pm 
Gilles MorisMay 9, 2010 1:49 pm 
Gilles MorisMay 9, 2010 1:49 pm 
Matt MackallMay 9, 2010 2:36 pm 
Matt MackallMay 9, 2010 2:43 pm 
Matt MackallMay 9, 2010 2:45 pm 
Matt MackallMay 9, 2010 2:47 pm 
Martin GeislerMay 9, 2010 4:11 pm 
Dirkjan OchtmanMay 9, 2010 10:50 pm 
Gilles MorisMay 9, 2010 11:31 pm 
Gilles MorisMay 9, 2010 11:49 pm 
Matt MackallMay 10, 2010 12:04 am 
Gilles MorisMay 10, 2010 12:37 am 
Gilles MorisMay 10, 2010 12:37 am 
Matt MackallMay 10, 2010 12:38 am 
Matt MackallMay 10, 2010 12:58 am 
Sune FoldagerMay 11, 2010 2:02 am 
Sune FoldagerMay 11, 2010 2:08 am 
Sune FoldagerMay 11, 2010 2:14 am 
Sune FoldagerMay 11, 2010 2:20 am 
Matt MackallMay 11, 2010 3:53 pm 
Matt MackallMay 11, 2010 3:56 pm 
Gilles MorisMay 12, 2010 12:52 am 
Gilles MorisMay 12, 2010 1:15 am 
Gilles MorisMay 12, 2010 1:15 am 
Gilles MorisMay 12, 2010 1:15 am 
Gilles MorisMay 12, 2010 1:15 am 
Gilles MorisMay 12, 2010 1:15 am 
Gilles MorisMay 12, 2010 5:17 am 
Augie FacklerMay 12, 2010 7:35 am 
Matt MackallMay 12, 2010 8:33 am 
Matt MackallMay 12, 2010 8:34 am 
Matt MackallMay 12, 2010 8:34 am 
Matt MackallMay 12, 2010 8:55 am 
Gilles MorisMay 12, 2010 2:33 pm 
Gilles MorisMay 13, 2010 7:31 am 
Matt MackallMay 13, 2010 1:48 pm 
Martin GeislerMay 17, 2010 1:09 am 
Martin GeislerMay 17, 2010 1:22 am 
Rafael Villar Burke (Pachi)May 17, 2010 2:07 am 
Augie FacklerMay 17, 2010 5:57 am 
Martin GeislerMay 17, 2010 6:56 am 
Augie FacklerMay 17, 2010 7:46 am 
Martin GeislerMay 17, 2010 8:13 am 
Augie FacklerMay 17, 2010 8:41 am 
Gilles MorisMay 19, 2010 8:00 am 
Martin GeislerMay 19, 2010 3:53 pm 
Martin GeislerMay 19, 2010 3:58 pm 
Augie FacklerMay 24, 2010 5:15 am 
Peter ArrenbrechtMay 26, 2010 6:23 am 
Rafael Fernández LópezJun 3, 2010 5:35 am 
Peter ArrenbrechtJun 3, 2010 6:14 am 
Martin GeislerJun 4, 2010 12:18 am 
Subject:Re: RFC: dealing with dead, anonymous feature branches
From:Martin Geisler (mg@lazybytes.net)
Date:May 19, 2010 3:53:02 pm
List:com.selenic.mercurial-devel

Gilles Moris <gill@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.

Fast and powerful revision control: http://mercurial.selenic.com/