Disable backing out merges?

Jason Harris jason at jasonfharris.com
Fri Oct 7 07:59:54 CDT 2011


> Maybe what we need is not a way to fix a broken merge but a way to
> tell users and mercurial that they should not _use_ that broken merge?
> 
> In one of my previous emails I proposed "closing" the invalid branch.
> It is not really a good solution but it was meant as a way to signal
> other users that a given revision should not be built upon.
> 
> Perhaps a better solution would be to add a mechanism to mark or "tag"
> a given revision as "invalid". The regular mercurial tag mechanism (or
> similar) could be used, where you could push these invalid tags as you
> push regular tags. People would get these "invalid tags" when pulling.
> Then mercurial could warn you if you tried to push revisions built on
> top of an "invalid" revision. Mercurial could also use that
> information when looking for common ancestors during a merge.


I wrote an extension for just this purpose:
   http://mercurial.selenic.com/wiki/ExcludeChangesetsExtension

It is known that in practice, bad merges, etc enter the repo. In this case we
have a design choice, do we complicate Mercurial further with some concept of
something like closed but actually invalid?

Or much simpler within the entire framework we just have the team leader or
someone turn around and say to the team:

"Whoops... We did blah blah blah and now we have some bad changesets in our
repository. Please check that you don't have made any further commits on top of
them and then run

hg strip 69cc2b0e47158d1a571a35ec89c5524b084944c9
hg strip a4988662d998b8d986bdaec43079475827aa31d0

on the repository.

Thanks, The team leader... "

Then the team leader just bar's these changesets via adding these hashes to the
repo/.excludedchangeset file.

Then they are gone from the repo forever. A miscreant user who hasn't read the
email can't re-push them since they have been barred / excluded on the servers
end.

Cheers,
   Jas



More information about the Mercurial-devel mailing list