To get your push through: try using mercurial 3.0.2.


To help diagnose you issue: Can you run the command using --debug?

Just switching to Mercurial 3.0.2 and pointing it to same repository resulted in same error message.

"hg push --debug" did not output much new, but here it is anyway:

pushing to https://kmansoft.codebasehq.com/kmansoft/kmansoft.hg
using https://kmansoft.codebasehq.com/kmansoft/kmansoft.hg
sending capabilities command
using auth.codebase.* for authentication
kmansoft.codebasehq.com certificate successfully verified
using auth.codebase.* for authentication
http auth: user kmansoft, password ********************
using auth.codebase.* for authentication
kmansoft.codebasehq.com certificate successfully verified
sending heads command
using auth.codebase.* for authentication
searching for changes
sending branches command
using auth.codebase.* for authentication
examining ae1e57506571:5818e803a04f
found incomplete branch ae1e57506571:5818e803a04f
searching: 1 queries
sending between command
using auth.codebase.* for authentication
narrowing 1:5 1ebd350367f6
narrowing 2:5 09fde0d17f5d
narrowing 4:5 c32b3fcd1312
narrowed branch search to 09fde0d17f5d:c32b3fcd1312
searching: 2 queries
sending between command
using auth.codebase.* for authentication
narrowing 1:2 d8bb6bedaa55
narrowing 2:2 c32b3fcd1312
found new branch changeset d8bb6bedaa55
found new changesets starting at d8bb6bedaa55
2 total queries
** unknown exception encountered, please report by visiting
** http://mercurial.selenic.com/wiki/BugTracker
** Python 2.7.6 (default, Nov 10 2013, 19:24:24) [MSC v.1500 64 bit (AMD64)]
** Mercurial Distributed SCM (version 3.0.2)
** Extensions loaded:
Traceback (most recent call last):
  File "hg", line 42, in <module>
  File "mercurial\dispatch.pyo", line 28, in run
  File "mercurial\dispatch.pyo", line 69, in dispatch
  File "mercurial\dispatch.pyo", line 138, in _runcatch
  File "mercurial\dispatch.pyo", line 819, in _dispatch
  File "mercurial\dispatch.pyo", line 599, in runcommand
  File "mercurial\dispatch.pyo", line 910, in _runcommand
  File "mercurial\dispatch.pyo", line 881, in checkargs
  File "mercurial\dispatch.pyo", line 816, in <lambda>
  File "mercurial\util.pyo", line 518, in check
  File "mercurial\commands.pyo", line 4717, in push
  File "mercurial\localrepo.pyo", line 1725, in push
  File "mercurial\exchange.pyo", line 131, in push
  File "mercurial\exchange.pyo", line 203, in _pushcheckoutgoing
  File "mercurial\discovery.pyo", line 317, in checkheads
  File "mercurial\discovery.pyo", line 317, in <genexpr>
  File "mercurial\node.pyo", line 18, in short
TypeError: 'NoneType' object has no attribute '__getitem__'

I was able to work around the issue by: 1) exporting each change as a patch 2) cloning the repository from a remote server 3) importing the patches one by one. This is with TortoiseHG 3.0.2.

Addind mads Kiilerich since his "unsynced head" warning is involved.

What does:

  hg incoming

says ?

At this point, "hg incoming" on the "bad" repo is finding the three commits I was able to re-do and push by cloning and importing each as a patch.

But -- and this is weird -- it also has one more commit, which I definitely pulled prior to making the three bad ones.

I'm able to reproduce.

This happen:

1. when pushing using --new-branch
2. to a server that does not supports the branchmap wireprotocol command.
3. with unsynced branch on server.

The following patch fix the symptom. Now looking why _oldheadssummary return some
None head in the first place.

  diff --git a/mercurial/discovery.py b/mercurial/discovery.py
  --- a/mercurial/discovery.py
  +++ b/mercurial/discovery.py
  @@ -309,11 +309,12 @@ def checkheads(repo, remote, outgoing, r
                               break
                       else:
                           newhs.add(nh)
           else:
               newhs = candidate_newhs
  -        unsynced = sorted(h for h in unsyncedheads if h not in discardedheads)
  +        unsynced = sorted(h for h in unsyncedheads
  +                          if h is not None and h not in discardedheads)
           if unsynced:
               if len(unsynced) <= 4 or repo.ui.verbose:
                   heads = ' '.join(short(h) for h in unsynced)
               else:
                   heads = (' '.join(short(h) for h in unsynced[:4]) +

About those None values:

Have you tried "amended" commits? 

I made one "regular" commit, then amended with some more changes, and finally made another amended commit. 

This last one had no changes to any files, just a different commit message. 

Don't know if it's valid, but the Eclipse plugin didn't object.

This is a valid usage of amend.

Upgrading your server should fixe the issue. Do you know what version of Mercurial is your server running?

No idea about server version - it's a commercial service, not my own.

Patch has arrive: http://www.selenic.com/pipermail/mercurial-devel/2014-August/060722.html

Can you ask them about the Mercurial version they use through their commercial support?

CodeBase is running v2.4-rc

Fixed by http://selenic.com/repo/hg/rev/70383c6961b4
Pierre-Yves David <pierre-yves.david@fb.com>
discovery: prevent crash on unknown remote heads with old repo (issue4337)

When a remote is not capable of the `branchmap` wireproto command, we denote
incoming heads with None. This leads to a crash in the code in charge of
displaying the list of unknown remote heads.

We now properly detect this case and display a shorter message in this case.

The reason for this  `set([None])` value is now documented.

(please test the fix)

I guess this means that mercurial server 2.4-rc, used by CodebaseHQ, does not support the branchmap command?

Is there a way for a simple-minded end user like myself to check server capabilities?

I have another commercial service in mind (which I also use) and would like to check its capabilities, to avoid surprises in the future.

You can check the content

  https://kmansoft.codebasehq.com/kmansoft/kmansoft.hg?cmd=capabilities

Your bug have been fixed and will be shipped in the next bug fix releases (september 1st).

If you can encourage CodeBaseHQ to upgrade that would be nice. 2.4-rc is a 2 year old release candidate.