Argh, big thanks. Indeed that was not obvious at all to me.

Leaving the "Assign To: [...]" field blank will remove assignees, but this is not obvious:

I believe there is very little reason for the "Autoclose" and "Publish" behaviors to actually be separate. That is, there are very few use cases where users want a commit to trigger only Herald or only feed or only audits. These use cases do exist (see T9210 for an example of "Herald, No Feed") but they're overwhelmingly niche and off-label.

In T6722#197239, @avivey wrote:

I think a more powerful approach is to support some kind of "templates", so that we can create a new "Android App" repo or "COM Module" repo directly, similar to how IDEs have project templates.

Sleeping on this, "FunctionChain" should just be a function chain(...) or compose(...) or something, which evaluates as compose(f, g, h)(x) => f(g(h(x))).

On selecting a domain, you can build a chain like this:

In a future diff, scale() and shift() take two arguments and work, although I'm likely rethinking exactly how the composition/chaining part of this works (see D20452 for rambling).

I'm think I'm going to tackle this a little differently. Mostly more rambling:

Also featured here is "load the data for all functions in the call tree, not just top-level functions".

• Small simplification.

Maybe the algorithm is:

This could be made slightly cleaner with a setSummary() to set a shorter summary:

The git fetch change in D20421 does actually affect non-bare repositories:

It looks like this does actually cause some issues with very old non-bare repositories. I'll follow up in T13280. I'm likely to move toward "users should convert these to bare repositories" over retaining non-bare support, since it's been at least like 4-5 years since we created non-bare repositories.

This is expected: the revision is not newly created.

This is expected: the revision is not newly created.