Annotating backouts

Gregory Szorc gregory.szorc at gmail.com
Thu Nov 14 10:31:27 CST 2013


On 11/13/13, 11:07 AM, Matt Mackall wrote:
> On Wed, 2013-11-13 at 10:58 -0800, Gregory Szorc wrote:
>> Transplant and graft write fields into changectx.extra to denote the
>> source changeset being cloned. This information can later be queried
>> through origin() and destination() to glean some useful info about how
>> changesets moved around inside the repository.
>>
>> I think it could be useful for backouts to record similar annotations.
>>
>> First, having these annotations would give repositories a more complete
>> picture of how changesets "evolve" over time. Currently, Mercurial makes
>> no attempt to identify a backout as such - it just looks like a normal
>> commit. I'm not sure if the Mercurial core could do anything useful with
>> a backout annotation. If not today, having this metadata would open
>> doors for future possibilities (although YAGNI applies).
>>
>> I think the real value of backout annotations would be user benefit. You
>> could have revset functions like backout() - select all changesets that
>> performed backouts - or backedout() - select all changesets that have
>> been backed out. You might even be able to construct a chain from
>> initial landing through a backout to final/sticking landing (although
>> this is a hard problem). This all could lead to some interesting code
>> metrics such as deriving a set of "risky" files/functions/lines that
>> have a history of being backed out or even identifying authors with a
>> tendency to get backed out.
>>
>> Is this something that would be considered for core or should it remain
>> in the realm of extensions? Would there be technically more to this
>> problem beyond stuffing a "backout_source" (or similar) field in extra
>> from inside the backout command?
>
> This seems reasonable.

Thanks for the endorsement!

I was thinking about this some more and there are some interesting edge 
cases and UX concerns.

1) `hg backout` only auto-commits if REV is the parent of the working 
directory. To ensure the extra annotation is eventually committed, we'll 
need to stuff the changeset somewhere and pick it up during eventual 
commit. This would require adding state to backout (not unlike rebase or 
histedit). Seems like a lot of work. Although arguably something that 
should be done already so e.g. backout auto-generated commit message can 
be used. How much should I care about getting this right?

2) Unpublished changesets could be interesting. It's tempting to say 
that we shouldn't push changesets with references to unpublished 
changesets. If the backed out changeset is an ancestor of ., we can 
assume that changeset will eventually be published. However, wouldn't it 
be better to say "you are reverting an unpublished changeset - why don't 
you remove the original changeset via rewriting history instead?" 
Although, I suppose we may want obsolescence enabled before going down 
that road. What about backing out an unpublished changeset that isn't an 
ancestor of .? Do we care if we push a changeset that references a 
changeset that may not exist in the remote? If we do, there are 
unfortunate history rewriting implications (since we'd need to update 
changectx.extra accordingly).


More information about the Mercurial mailing list