backout reports an arguably spurious conflict when backing out the creation and modification of a file

[Matt Mackall]

On Mon, 2012-08-06 at 12:23 +0100, Tom Anderson wrote:
> Morning all,
> 
> I don't always back out old changesets, but when i do, i back out 
> several at once. This is a natural consequence of the "commit early, 
> commit often" philosophy, which my colleagues and i vigorously embrace.
> 
> However, backout does not always handle this as gracefully as would be 
> ideal. In particular, if we have added a file in one changeset and 
> modified it in a later one, then if i back out the later (modifying) 
> changeset, backout is skittish about removing the file when i then back 
> out the earlier (creating) changeset.
> 
> By way of example:
> 
> $ hg --version
> Mercurial Distributed SCM (version 2.3)
> (see http://mercurial.selenic.com for more information)
> 
> Copyright (C) 2005-2012 Matt Mackall and others
> This is free software; see the source for copying conditions. There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> $ hg init foo
> $ cd foo
> $ # this file and changeset are irrelevant; they're just there to give 
> us some history
> $ hostname >hostname
> $ hg add hostname
> $ hg commit -m 'added hostname'
> $ date >date
> $ hg add date
> $ hg commit -m 'added date'
> $ sleep 1; date >date
> $ hg commit -m 'updated date'
> $ hg log
> changeset:   2:4fd92dcb8b2a
> tag:         tip
> user:        Tom Anderson <tom.anderson at timgroup.com>
> date:        Mon Aug 06 12:11:28 2012 +0100
> summary:     updated date
> 
> changeset:   1:d35284536be0
> user:        Tom Anderson <tom.anderson at timgroup.com>
> date:        Mon Aug 06 12:11:27 2012 +0100
> summary:     added date
> 
> changeset:   0:80e53477a8de
> user:        Tom Anderson <tom.anderson at timgroup.com>
> date:        Mon Aug 06 12:11:27 2012 +0100
> summary:     added hostname
> 
> $ hg backout 2 -m 'backing out 2'
> reverting date
> changeset 3:79460afd05d0 backs out changeset 2:4fd92dcb8b2a
> $ hg backout 1 -m 'backing out 1'
> removing date
> remote changed date which local deleted
> use (c)hanged version or leave (d)eleted?
> 
> If i respond 'd', things continue:
> 
> 0 files updated, 0 files merged, 0 files removed, 0 files unresolved
> $ hg status
> R date
> 
> This is the correct outcome. However, it would have been nice if i 
> hadn't been prompted about what to do. I was pretty baffled when i first 
> saw that; in the real case, it referred to a file i wasn't familiar 
> with, because i was backing out someone else's changes. It didn't take 
> long to work out that it was a spurious complaint, but it would have 
> been nice if i hadn't had to.
> 
> I understand why this is happening: the file i am removing has indeed 
> been modified by later changesets. However, the state that it is 
> currently in is identical to the state that resulted from the changeset 
> i am trying to back out, and so really, it's clean and safe to remove it.
> 
> This isn't exactly a bug, but it strikes me as a rough edge that could 
> be smoother. Should i raise a bug for this?

No, this behavior is correct. You asked Mercurial to undo changeset X,
not X + Y + Z, and it's discovered it can't do that in an unambiguously
safe fashion.

-- 
Mathematics is the supreme nostalgia of our time.