Bug 3421 - Editing a file between hg commit and the actual commit
Summary: Editing a file between hg commit and the actual commit
Status: RESOLVED WONTFIX
Alias: None
Product: Mercurial
Classification: Unclassified
Component: Mercurial (show other bugs)
Version: unspecified
Hardware: All All
: normal bug
Assignee: Bugzilla
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-05-03 04:48 UTC by romkyns
Modified: 2012-05-13 04:59 UTC (History)
5 users (show)

See Also:
Python Version: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description romkyns 2012-05-03 04:48 UTC
Mercurial behaves inconsistently if a file is edited while the commit
message editor is open.

Correct alternative 1: The change is completely bundled up, and only the
commit message is pending. Any further edits at this point make no
difference to what ends up committed.

Correct alternative 2: Nothing is done until the commit message is entered.
Once it's entered, the commit operation goes ahead, committing all changed
files.

Current, inconsistent behaviour: any further edits to files that already had
edits in them will be committed, but any further edits to files which
weren't edited before "hg commit" was issued will be ignored.

The current behaviour goes against the nature of "hg commit", namely
committing all files that differ to the repo.
Comment 1 kiilerix 2012-05-03 05:02 UTC
The commit message template do list the files that will be committed. It
would be even more confusing if changes made to these files while editing
the commit message wasn't included.

It would be a different story if the commit template included a diff of the
changes that would be committed; then the actual commit should do just that.
Comment 2 Idan Kamara 2012-05-03 05:29 UTC
Including additional changes of only the files displayed in the commit 
message is just odd.

I don't think the behavior should be dictated by what's currently displayed 
in the editor by default. It could be that users (like me) had a diff 
displayed in there too (like the script 'hgeditor' does in the repository 
root).

Since option 1 is backward incompatible, option 2 might be better.
Comment 3 Patrick Mézard 2012-05-03 05:38 UTC
"Since option 1 is backward incompatible, option 2 might be better."

The current behaviour was probably unspecified, not sure backward
compatility matters much here.
Comment 4 Matt Mackall 2012-05-03 10:51 UTC
I'm frankly inclined to say "won't fix".

For a long time, the behavior was: finish every piece of the commit except
the commit message, then run the editor while holding the lock. This turned
out to cause problems in a bunch of areas and we spent a long time getting
from there to here. In other words, option 1 is already known to be
unworkable. We finally changed this in May 2009. Among other things, this
means that aborting a commit doesn't require a rollback.

Option 2 is also also unworkable: since we can't lock the filesystem, it's
impossible to prevent races, and expensive to try. We would need to either
buffer all the (possibly large) changes somewhere or make a second pass over
the working directory for new changes. And now users who expect that commit
committed only the files it said it was going to (a quite reasonable
assumption) will be disappointed.

So we have option 3: Mercurial decides what files it's going to commit,
tells you what files it's going to commit in the editor, and then commits
them. I see this as a less inconsistent than option 2.
Comment 5 Bugzilla 2012-05-12 09:30 UTC

--- Bug imported by bugzilla@serpentine.com 2012-05-12 09:30 EDT  ---

This bug was previously known as _bug_ 3420 at http://mercurial.selenic.com/bts/issue3420