Disable backing out merges?

Jason Harris jason at jasonfharris.com
Sat Oct 8 03:38:45 CDT 2011

On Oct 8, 2011, at 3:43 AM, Angel Ezquerra wrote:

> On Fri, Oct 7, 2011 at 2:59 PM, Jason Harris <jason at jasonfharris.com> wrote:
>>> 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 haven't made any further commits on top of
>> these bad changesets 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
> This is quite nice!


> I must say that I found the name of the .excludedchangeset file a bit
> weird. I would expect that the name of any mercurial related config
> file would start with ".hg".

Actually, this is a good point. Upon reflection I have thought making the name banned instead of excluded might be better since Mercurial already has an exclude option running around. So maybe a little clearer (and possibly less confusing)

Maybe I should change the names to:
extension name: BanChangesets
config file name: .hgbannedchangesets

Would that be better?

> Also, is there a reason why you limit the excluded changeset
> definition syntax to explicit node ids? You could perhaps extend the
> syntax to allow revsets as well. That way you could for example
> exclude commits performed by a given user or in a given time period,
> or containing a given file, etc.

Excluding / Banning via changeset id was the simplest thing to do at the time. This was the use case we had where some stuff up occurred and we wanted to make sure these bad changesets didn't seep back into the repository. I guess the extension could easily be extended. Patches are very welcome :)


More information about the Mercurial-devel mailing list