Superseded by 2329, which has a repro recipe - http://mercurial.selenic.com/bts/issue2329

Copying 2053 nosy to 2329.

Now I am pretty sure that this bug is caused by the attic extension. Disable
attic get rid of the problem. Since Bill Barry is the author of attic
extension, I believe he has the extension enabled as well.

Two more observations:
* I cannot reliably reproduce the bug. 
* When the bug shows up, try the following sequence of commands, the bug
will disappear again:
  $ hg st  # showing several files modified
  $ hg ci fileA  # launch the editor, showing *all* modified files are to be
commited
  $ # commit all files by mistake
  $ hg rollback  # found the mistake, rollback
  $ hg ci fileA  # this time, showing only fileA

I encountered the same problem with v1.4.3. I have two files (file1 and
file2) modified in the repository. "hg commit file1" will list both file1
and file2 are to be committed.

I suspect the problem is file system dependent, as I only have this problem
on one machine with Lustre parallel file system. Cloning the repository to a
normal file system on the same machine, the problem disappears. 

I am willing to debug and fix the problem, but I am not familiar with hg
internal. Any guidance on how to debug it further?

was the 'file' not committable?  I'm quite confused by this.  The only way I
can imagine this happening is if the filename was confused with a command
argument.

I can't reproduce this with Mercurial 1.4.1 and TortoiseHg 0.9.1.1 on Windows, 
at least. It commits single files at a time fine.

I tried just now to commit one file with:
hg commit file -m "..."
and it committed everything.

This command should either fail or work properly, not what it currently does.

using Mercurial-1.4.3+159-7a6b5f85c3ab
via TortoiseHg version 0.9.3+115-afa14c7858a1

(from DOS prompt)