It's supposed to be sent with the call to the external build system, but that doesn't seem to work either -- the build target phid received is always ''.

Would this be possible for #prioritization? I would work on it myself, but don't have any ideas for an appropriate fix.

I'd be inclined to show N branches, for some small value of N like 3 or 5 or 10, with a link to "Show 1,695 more branches which contain this commit...".

Actually I think we can go even deeper (T3462).

This has been fixed in master and cherry-picked into stable (as rPc0a52201). You should be able to update to pick up the fix.

Unfortunately, no part of that sounds well-aligned with our thinking about the roles for these applications or our roadmap for the products. If your development workflow routinely has changes which are too large for Differential to reasonably accommodate (20K+ lines?), it is far outside of my experience in software development and Phabricator is probably not a good tool to use for this workflow.

Not sure if any of this is relevant to T8297, but everyone loves walls of text!

I think that change is tentatively within the realm of reason, but I have some concerns.

You have a version of cURL which has a bug with Content-Length (see T8654 for discussion), but your version of libphutil should include a workaround, so I'm not sure what's up. I can't reproduce this problem on this server.

At HEAD:

Can you show me the output of these commands on the server?

Other known demons are spaces (T7305), colons (T7341), and sort-of-but-not-really hyphens (T9480).

Blueprint selection (which got more details in T9519) is now in a rough-but-functional state so I expect the rest of this to move forward shortly.

You can change the configuration. This protocol is not prevalent enough to motivate us to include it by default in the upstream.

Particularly, the command server wire protocol is completely different from the HTTP/SSH wire protocol (and pretty reasonable overall, although it's solving a much simpler problem).

We have some CommandServer stuff too, although I don't think it has ever been reachable from the UI. I don't remember if the original use case was improving arc performance or improving import/parser performance.

So we probably need to special case the unbundle command, decode the response, build additional parts from stderr, and then insert them into the response.

I suspect it's worthwhile for us to support bundle2 eventually. As far as I can tell from my investigations in T9450:

Technically, we could implement "To", "Cc", "Any Recipient", and maybe "Sending application" or "Object type" outbound Herald fields today so you could write some variant of this:

Well, I don't expect to actually fix any of this for like 20-30 years, I'm just filing it.

The actual skin would also be bad for a Medium-alike with a huge image of a tree or a house or whatever at the top since you couldn't preview it meaningfully.

I'm trying out Phame for providing companion notes to the Changelog so I'm going to file some stuff I hit. This is probably mostly stuff that we would have naturally fixed anyway, but some of it isn't totally obvious.

Yeah, that seems reasonable to me. You can already "Close Branch" today which is effectively the same action as "Freeze Release". I'm broadly comfortable with moving Harbormaster in the direction of having richer application awareness and interactions, although we'll have to think a bit about what happens when you "Freeze Release" in a build plan and run it on a commit (does it fail? get skipped? configurable?).

• Go to a Branch/Release page.
  • Click the "New Pull Request" button.
  • That goes into the queue for the Branch/Release.
  • Whoever owns the Branch/Release can approve/reject it.
  • That's the end of the workflow today since Harbormaster didn't exist and none of T182 was planned. Last I knew, Facebook completed the rest of the workflow with custom arc do-a-bunch-of-git-stuff extensions.

(The pull requests are just useless outside of the Facebook workflow because they can't merge and the "you can do hundreds of them really quickly" aspect isn't useful at less-than-Facebook scales.)

"Pull Requests" are the existing "Pull Requests" in Releeph. They're literally just pull requests. Releeph today is like 90% about implementing pull requests and then 10% about surfacing pertinent details about those requests prominently so chuckr and peers can bulk process hundreds of them per day.

Specifically, here are three workflows with different levels of mutability that I'd like to support:

(In this case I think your behavior is the more natural one and I'd probably want to tell the hypothetical future users wanting the other behavior to go build a custom version of "land" via T5055 with one million flags, and they may not really exist, I just want to have some sort of contingency plan in mind before making the change.)

Release will be as immutable as possible

A culvert is just a big drainpipe.

Per the title, the issue is that the description column on DifferentialDiff is declared as text255? for historical reasons that have been lost to the ages, but should just be text.

@jshirley, the project detail page should have a "Hashtags" field which lists the tags that will work. "/" should never be part of a hashtag. The value that will work is probably something like "team_oncall" by default, but you can customize that by adding or changing the hashtag.

Anyway, pretty much same story here as T9537 -- I want to sort out T3855 better first, then we can tackle refinements here.

I guess that won't quite do what you want since you're legitimately tracking a local branch which tracks a different remote branch in this case. But maybe you're partially doing this only because T9537 doesn't work?

I think we probably solve this incidentally by doing T3855, T9537, making --onto mean in the remote, and defaulting it to the tracked branch (although I think it already does?). The only problem with this is that land-example wont get updated but from T9537 maybe you're completely fine with that?