On Mon, Jun 28, 2010 at 7:46 PM, Matt Mackall <mp...@selenic.com> wrote:

Indeed... I just tried "hg backout" with an empty commit message, and I think I have reproduced Jørgen's problem:

1) Start with a repository with one commit only:

% ls file-A % hg log changeset: 0:218a0afc8e6c user: Daniel Carrera <dcar...@gmail.com> date: Mon Jun 28 19:48:14 2010 +0200 summary: Initial commit

2) Reproduce the error:

% touch deleteme % hg add deleteme % hg commit -m 'Bad commit'

At this point Jørgen ran "hg backout tip", he saw a text editor, and he *removed* the commit message, leaving the file blank. He was trying to abort the backout, and it sort of succeeded:

% hg backout tip (erase the commit message and save) removing deleteme abort: empty commit message % hg log changeset: 1:59c7f10682a8 tag: tip user: Daniel Carrera <dcar...@gmail.com> date: Mon Jun 28 19:48:37 2010 +0200 summary: Bad commit

changeset: 0:218a0afc8e6c user: Daniel Carrera <dcar...@gmail.com> date: Mon Jun 28 19:48:14 2010 +0200 summary: Initial commit % hg ls file-A

Now, the "backout" action was aborted, but it nonetheless deleted the file.

I think *THIS* is the key issue: If you abort a "backout", Mercurial will *STILL* remove the files.

Of course, if you "rollback" now, you lose your previous commit and Jørgen's data is gone forever.

I think this points to a legitimate issue with Mercurial: If the "backout" command aborts, it *should* *not* delete the files. To me, "abort" means "abort", it means that the aborting command does not go ahead and make the change that it claimed to have aborted.