Ok, thanks. It may be useful to mention the Ref T123 format in the docs or elsewhere. I wasn't aware of it at all, and it doesn't appear to be in the docs.

It'll also help to avoid confusion since the "close" behavior seems more natural for workflows such as ours -- all our developers assume that either approach (Web UI or "Maniphest Tasks") should create a "close" relationship and that the actual behavior is a bug.

A related issue surfaced recently. Actual use case (forensically reconstructed):

• A user wrote Fixes TT... (instead of Fixes T..., note double TT) in a message by accident.
• When they noticed the mistake, they (probably) manually used Edit Related Objects → Edit Tasks to add a link between the revision and the task.
• When this commit landed, the commit and task did not get an edge between them.

The current behavior of the piece of code which creates the <Commit, Task> edges is to parse the message for "magic words" in the form of Fixes T123, add edges for any it finds, and then change the relevant task statuses.

This means:

• (From reading the code only, I haven't verified this) If you write Ref T123 in a commit message, only the revision (not the commit) gets linked to the task because the phrase doesn't change the task's status.
• If you add links from the web to the revision, they aren't carried over to the commit since we don't look at edges on the revision.

I'm not entirely sure what to do about this. One additional factor is that the instance ran into this because they were using a script to compile a changelog-like record of changes, not because humans were confused, so the root problem was more one of changelog compilation rather than usability, per se.

At a minimum, I think the Ref T123 behavior is probably inconsistent and undesirable. If you push a Ref T123 commit without a revision, you should probably get an edge.

I'm somewhat less sure about copying edges in the general case, although I think it's probably correct to say that Ref T123 and Edit Related Objects → Edit Tasks should be as close to equivalent as possible.

Part of the issue is that commits are a bit special. For other types of objects, we organize relationships in a "hub and spokes" pattern with tasks at the center. This is generally good but Commits/Revisions get to break these rules and be related to one another directly. (This also gets a bit muddier with things like Builds and, in the future, perhaps release-related objects from T9530).

It feels kind of bad to just copy edges, since copying things is The Greatest Evil In Software, but I think this is mostly a theoretical problem and works fine in practice.

An alternative is to limit or reduce copying and guide installs instead: "If you're compiling a changelog, follow the edge to the revision and then find tasks from there, in addition to tasks on the commit: it is possible that not all tasks are linked directly to the commit.". Regardless, this guidance is true in the general case, because tasks may be linked to a revision after commits for it land.

T11934 is a possible way forward on this (and other niche things) without adding a lot of Javascript and UI complexity, by supporting it through !fixes.