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.
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.
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.
"Since option 1 is backward incompatible, option 2 might be better." The current behaviour was probably unspecified, not sure backward compatility matters much here.
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.
--- 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