Feb 18 2019
I'd propose for simplicity that the focus switch from largefiles to lfs support for Mercurial repositories. lfs has been added to Phabricator for Git already T7789 and it seems that there'd be less work involved to piggyback on that.
Oct 25 2018
May 16 2018
Mercurial 4.6 has added hg help internals.bundle2 which will render a book to your console with details about the format/protocol. I did a high-speed skim and then tried out hg help internals.changegroup on a whim which produced an even longer book about the stream protocol (SSH only maybe?).
Apr 11 2018
Actually turns out that the work around isn't reliable - I still get that error occasionally (I'm using SSH)
Mar 11 2018
For recent versions of mercurial to work over http I had to force httpheader=1024 in code which filters bundle2 capabilities.
Mar 5 2018
Jan 25 2018
Presuming this is resolved since we've seen at least some confirmation that it fixed issues and aren't aware of any remaining outstanding problems.
Jan 16 2018
I'm not totally sure all variants of this are fixed, but I don't know how to reproduce any remaining issues.
I filed a summary of this in the Mercurial upstream to waste someone else's time so I feel better:
This is an explicit behavior in Mercurial and dates from 2007:
The rule Git uses appears to literally be "does the filename include a space":
Jan 9 2018
I'm going to close this since it was mostly answered and the remaining questions (about custom extension development) are outside the scope of modern support. See T13039 for a followup about numeric fields in Herald.
Ah, thanks! This is probably effectively covered by T9948 anyway -- one of the major changes for the Git flavor of that (T9657) was "put things back the way they were when anything goes wrong, even if we discard merge/rebase work", and that seems like a better behavior. I'll make a note there just in case.
Jan 8 2018
I tried a few scenarios for this and wasn't able to reproduce
- Single commit in diff that creates conflict
- Multiple commits in diff that all create conflicts
- Single commit in diff where first commit does not create conflict but second does
Jan 5 2018
Jan 4 2018
After D18857, I'm not aware of any remaining, reproducible issues with Mercurial. If you're still encountering protocol issues after upgrading through D18857, let me know how to reproduce the problem you're seeing.
Mercurial's protocol negotiation presumably considers the size of the change being transmitted in selecting the protocol format
I think D18857 fixes the pipe issues. Here's the problem:
Here's some evidence [that filtering bundle2] doesn't work:
we attempt to filter the protocol and tell the client that we don't support bundle2
Actually, this is less crazy than I thought.
This appears to date back to the introduction of the feature in D5738, where I suggested we use ancestors() without a legitimate reason (or maybe very old Mercurial had weird behavior).
We can't reproduce this, and can't fix issues we can't reproduce.
Nov 21 2017
That's a good point! I wish it was designed like that since the beginning. I guess it won't happen with the current compatibility rules since it is likely to break automation.
In theory, you could require --config appear between hg and foo in hg foo .... This is already a valid position for --config (for example, hg --config x=y foo is valid), and already not a valid position for foo flags (for example, hg --branch default log is not valid).
https://phab.mercurial-scm.org/D1483 should make it possible to use -- to defend against non-flag user input. For inputs that are flags, use the form --flag=X and avoid --flag X.
Nov 13 2017
We'll use the hardened mode once it's available, but I don't think we expect to take any further action here until then.