https://bz.mercurial-scm.org/show_bug.cgi?id=5549
Bug ID: 5549 Summary: Dirty state indication is inconsistent with missing files Product: Mercurial Version: default branch Hardware: PC OS: Windows Status: UNCONFIRMED Severity: bug Priority: normal Component: Mercurial Assignee: bugzi...@mercurial-scm.org Reporter: matt_harbi...@yahoo.com CC: fo...@lares.dti.ne.jp, mercurial-devel@mercurial-scm.org I think it's a reasonable assumption that '!' files means wdir() is dirty, but that's not always indicated as such. See the script below for the various scenarios. The file() revset one is likely a different underlying issue, but raised to show the big picture relating to '!' state. There may be other inconsistencies. The subrepo case at the end may be worth a separate issue, if that's not the expected behavior. $ hg init repo $ cd repo $ touch foo.txt bar.txt $ hg ci -Aqm foo $ rm foo.txt $ hg st ! foo.txt For a plain `rm`, identify has a '+', indicating dirty... $ hg id 4f35d387dc39+ tip ... but summary says it is clean. $ hg sum parent: 0:4f35d387dc39 tip foo branch: default commit: 1 deleted (clean) update: (current) phases: 1 draft The file() revset doesn't notice '!' state... $ hg log -r 'heads(. or wdir() & file("**.txt"))' -T "{rev}\n" 0 ... but does notice 'M' state $ echo mod > bar.txt $ hg log -r 'heads(. or wdir() & file("**.txt"))' -T "{rev}\n" 2147483647 $ hg up -Cq . $ hg clone -q . subrepo $ echo "subrepo = subrepo" > .hgsub $ hg ci -Aqm subrepo $ echo mod2 > subrepo/foo.txt $ hg ci -Sm mod2 committing subrepository subrepo $ hg up -q '.^' $ echo mod3 > subrepo/bar.txt $ hg ci -Sm mod3 committing subrepository subrepo created new head $ rm subrepo/foo.txt $ hg st -S ! subrepo/foo.txt identify and summary don't notice '!' in a subrepo at all... $ hg id be0bc0d77261 tip $ hg sum parent: 3:be0bc0d77261 tip mod3 branch: default commit: (clean) update: 1 new changesets, 2 branch heads (merge) phases: 4 draft $ hg log -R subrepo -G -Tcompact @ 2[tip]:0 aff7ac8f4c46 1970-01-01 00:00 +0000 test | mod3 | | o 1 93c1d5f22559 1970-01-01 00:00 +0000 test |/ mod2 | o 0 4f35d387dc39 1970-01-01 00:00 +0000 test foo ... but merge does. I'm a bit surprised that the local revision isn't listed as aff7ac8f4c46+ (I thought that it used to be, but generally avoid merges with a dirty subrepo, so I might be wrong.) $ hg merge subrepository subrepo diverged (local revision: aff7ac8f4c46, remote revision: 93c1d5f22559) (M)erge, keep (l)ocal [working copy] or keep (r)emote [merge rev]? m abort: uncommitted changes (in subrepo subrepo) (use 'hg status' to list changes) [255] The top level merge doesn't always fail with a dirty subrepo. Should it have, since --force wasn't provided? (`help merge` doesn't mention aborting when dirty, and --force is now hidden as deprecated, so there's no explicit documentation to weigh this against.) $ echo "l" | hg merge --config ui.interactive=Yes subrepository subrepo diverged (local revision: aff7ac8f4c46, remote revision: 93c1d5f22559) (M)erge, keep (l)ocal [working copy] or keep (r)emote [merge rev]? l 0 files updated, 0 files merged, 0 files removed, 0 files unresolved (branch merge, don't forget to commit) $ hg up -C . 1 files updated, 0 files merged, 0 files removed, 0 files unresolved $ echo mod3 > subrepo/foo.txt identify and summary will notice 'M' files in a subrepo... $ hg id be0bc0d77261+ tip $ hg sum parent: 3:be0bc0d77261 tip mod3 branch: default commit: 1 subrepos update: 1 new changesets, 2 branch heads (merge) phases: 4 draft ... and merge aborts fast with 'M' files in a subrepo $ hg merge abort: uncommitted changes in subrepository 'subrepo' [255] -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel