Browsing Diffusion (namely, loading a file while the published changeset is head, and trying to Skip past commit):

I couldn't immediately reproduce this; it's also probably a bit of a messy fix.

I'll plan to investigate further if possible. I believe in this case the repository was running in observed mode rather than hosted in case that might be a factor.

Browsing Revision

I caught one cosmetic issue in D21711, but this works properly for me locally now. Thanks!

(After picking up D21697, the approach works properly in my environment where I originally ran into this, but there are a couple of rebase calls still present in ArcanistMercurialLandEngine that don't use the new API yet.)

I'm also surprised that rebase extension isn't enabled by default. I guess I have been turning it on in my default setup.

I like that idea. I'll take a look.

...perhaps we should consider a way to do this automatically or at least less-manually.

The current ls-remote script as written does not actually work; I think it only returns branches in the remote that:

The actual extension is a 100-line Python script...
The real Pandora's box this opens...

The real Pandora's box this opens is that now that arc is exposed to whatever issues arise with the raw Python/Mercurial API, there's a much weaker argument against not writing more extensions.

I put the extension in phabricator/ earlier by accident, but that was just me goofing my local paths. The extension is purely client side: hg can do ls-remote just fine (it's just "do hg pull, but stop half way through"), there's just no UI command for it.

Would the use of an extension make additional setup necessary for observed repositories vs. hosted repositories, or are observed repositories out of scope for these set of changes?

I am considering reviving the command server since I don't remember it having any critical failures, but offhand:

I'm going to try writing a Mercurial extension instead.

I believe this is roughly the form we end up with, which is completely ridiculous and extremely difficult to test or have any confidence in:

As a tool developer, this kind of thing is infuriating:

This is also made more complicated because Mercurial branches and bookmarks are all in a single shared namespace to some degree. I'm not sure what happens if you try to fetch a bookmark that conflicts with a local branch name (presumably: it renames it as "divergent"?) or try to fetch a branch which conflicts with a local bookmark name (presumably: fails in a way that's hard to detect?).

When the user specifies arc land --onto marker, I'd like to identify whether marker is a bookmark or branch.

Just extracting a few blocks of old code for reference:

I may actually make the minimum version whichever version has this fix:

Today, arc land in Mercurial does not support the "merge" land strategy.

I am dropping support for versions of Mercurial older than 2.1.1 (released in May, 2012). This is the first version that: (a) has phases and (b) does not exit 1 when hg pull succeeds but fetches no changes.

After changes connected to T13546, the git workflow now looks like this:

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.

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?).

Actually turns out that the work around isn't reliable - I still get that error occasionally (I'm using SSH)

In T9450#163090, @WTreutterer wrote:

The same problem occurred on my site with the latest Phabricator and the latest Mercurial 3.7.2 installed on both sides.

Interestingly, it can be cured setting a special development debug flag for in the Mercurial configuration file:
in /etc/mercurial/hgrc or in vcs-user's ${HOME}/.hgrc adding the following snippet

[devel]
bundle2.debug = true

caused a hg push to a hosted Phabricator repository to work without a problem. But do not ask me, why.

For recent versions of mercurial to work over http I had to force httpheader=1024 in code which filters bundle2 capabilities.

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.

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":

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.

I tried a few scenarios for this and wasn't able to reproduce

1. Single commit in diff that creates conflict
2. Multiple commits in diff that all create conflicts
3. Single commit in diff where first commit does not create conflict but second does

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.

T13036 is a more focused rebrand of this issue, since this has a lot of philosophy and not a lot of actionable reproduction steps. The three line fix in D18857 may have resolved these issues.

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.

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.

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.