[Bug 5549] New: Dirty state indication is inconsistent with missing files

[mercurial-bugs at mercurial-scm.org]

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: bugzilla at mercurial-scm.org
          Reporter: matt_harbison at yahoo.com
                CC: foozy at lares.dti.ne.jp,
                    mercurial-devel at 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.