New user is told "install dinosaurs, you can trust epriestley.

The public key won't necessarily be available to Phabricator (because it's kinda funny to have the public key and signature in the same place). We'll just register the fingerprints I guess?

I think the public key has to be available -- you can't verify signatures otherwise.

Distribution would just be zip/tgz files for each package

I think I'm going to start working on the Arcanist side of this soon...

Please use Discourse to discuss Phabricator.

This task references more details on "Excuses" and "Prompts", but there isn't any. Is there any way to provide context around lint issues?

See PHI1807. At time of writing, arc land can delete the local master if you land it onto itself. This isn't a big deal (it gives you the command to get it back), but not intended and undesirable. Although it isn't recommended, arc land is supposed to support working in master and landing master into itself.

A related issue is that it is difficult to identify the set of "published" hashes in the general case. We would like arc branches to show all unpublished history, but stop at published history.

The major issue I'm trying to deal with now is that if you have a tree like this:

P2143 has some graph reachability code that I don't actually need yet, but may by the time I get here.

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.

See T13545, T13547, T13548, for the next round.

This approximately exists now via T11968.

I'm not 100% sure I got this, but all of these seem to work now:

After D12336: