hg commit doesn't catch changes made during editing of commit messages

Rob Browning rlb at defaultvalue.org
Thu Sep 22 13:45:22 CDT 2005


Matt Mackall <mpm at selenic.com> writes:

> 1) Mercurial doesn't launch $EDITOR until everything except the
> changeset description itself is committed.
>
> 2) Mercurial doesn't update the dirstate of files until it's
> completely finished the commit, so files changed while in the commit
> are marked clean though not committed

> The first is a little peculiar and suboptimal. The reason is mostly to
> do with signing. To sign, we need to have calculated the manifest
> hash, which means we need to have calculated the file hashes, which
> means we need to have committed everything. Then we can pass the
> manifest hash off to $EDITOR and get things signed. 
>
> This has the downside that the repo is locked longer while you're
> composing your message, but since repos are mostly private, this
> doesn't matter. It also has the confusing side effect of not
> committing changes you make while in $EDITOR.
>
> The second is perhaps a bug. Getting rid of the race entirely will be
> tricky.

If I understand that right, then yes, that seems bad.

For example, if you're double-checking/updating your commit message in
while in the $EDITOR by looking at the output of "hg diff" it seems
likely that you might notice some error in the diff, and then go fix
it.  I know I've done that sort of thing in the past.

If nothing else, would it be possible to just detect that files were
changed during the commit and just abort/rollback with an error
message instead of finishing?


Actually, the reason I came across this thread is that I was trying to
check for previous requests before asking about a possible change in
commit's behavior, a change which I suspect is affected by the issues
above.

Right now, if hg commit doesn't find the logfile specified by "-l", it
will just continue anyway and launch $EDITOR.  In my case, the reason
it didn't find the logfile was that I had mistyped the path.  I really
wanted mercurial to abort and let me try again rather than just
proceeding.

It would also be nice if there were some way to abort a commit (for
example, if you realize you've made some kind of mistake while editing
the commit message).  I've seen other systems that will ask you what
you want to do if the commit message remains unmodified after you exit
$EDITOR, although just handling a SIGINT gracefully would be fine.

Also, what happens if mercurial can't find the -l file and $EDITOR
fails?  Does the commit proceed anyway, or does it rollback?

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


More information about the Mercurial mailing list