[Bug 4632] New: Pushing hidden changesets no-ops and results in confusing behavior

[mercurial-bugs at selenic.com]

http://bz.selenic.com/show_bug.cgi?id=4632

          Priority: normal
            Bug ID: 4632
                CC: mercurial-devel at selenic.com
          Assignee: bugzilla at selenic.com
           Summary: Pushing hidden changesets no-ops and results in
                    confusing behavior
          Severity: bug
    Classification: Unclassified
                OS: All
          Reporter: gregory.szorc at gmail.com
          Hardware: All
            Status: UNCONFIRMED
           Version: 3.4-rc
         Component: Mercurial
           Product: Mercurial

The behavior when attempting to push hidden changesets is confusing.

>From 3.4-rc+61-bff42a92012e and mutable-history 35d8789ea7a8 (5.1.4).

Assuming 690a034b2d15 is a hidden changeset:

  $ hg push -r 690a034b2d15 user
  pushing to ssh://hg.mozilla.org/users/gszorc_mozilla.com/gecko
  abort: hidden revision '690a034b2d15'!
  (use --hidden to access hidden revisions)

OK, so I'll add --hidden to force it to push.

  $ hg --hidden push -r 690a034b2d15 user
  pushing to ssh://hg.mozilla.org/users/gszorc_mozilla.com/gecko
  searching for changes
  no changes found

Oh, so I must have already pushed!

  $ hg pull -r 690a034b2d15 user
  pulling from ssh://hg.mozilla.org/users/gszorc_mozilla.com/gecko
  abort: unknown revision '690a034b2d15'!

Huh?

Throwing some --debug into the mix, we see discovery is being performed, but we
are failing to send any changesets.

  $ hg --hidden push -r 690a034b2d15 user --debug
  pushing to ssh://hg.mozilla.org/users/gszorc_mozilla.com/gecko
  running ssh hg.mozilla.org 'hg -R users/gszorc_mozilla.com/gecko serve
--stdio'
  sending hello command
  sending between command
  remote: 153
  remote: capabilities: lookup changegroupsubset branchmap pushkey known
getbundle unbundlehash batch stream unbundle=HG10GZ,HG10BZ,HG10UN
httpheader=1024 pushlog
  remote: 1
  query 1; heads
  sending batch command
  searching for changes
  taking initial sample
  searching: 2 queries
  query 2; still undecided: 28012, sample size is: 200
  sending known command
  sampling from both directions
  searching: 3 queries
  query 3; still undecided: 8689, sample size is: 200
  sending known command
  sampling from both directions
  ...  
  query 17; still undecided: 16, sample size is: 16
  sending known command
  17 total queries
  preparing listkeys for "phases"
  sending listkeys command
  preparing listkeys for "namespaces"
  sending listkeys command
  checking for updated bookmarks
  preparing listkeys for "bookmarks"
  sending listkeys command
  no changes found
  preparing listkeys for "phases"
  sending listkeys command
  try to push obsolete markers to remote
  preparing listkeys for "namespaces"
  sending listkeys command

I'm not sure what the proper behavior should be. But surely anything is better
than the ambiguous result we currently have.

-- 
You are receiving this mail because:
You are on the CC list for the bug.