Please use the Discourse forum for this kind of discussion.
I think that's reasonable -- if there are at least, say, 11 consecutive lines affected only by the same indentation level change (or the line is blank), we could show the first 3, fold the middle 5+, then show the last 3.
!== 0 and !== mask have different meanings when mask has multiple bits set. Today, IMPORTED_CLOSEABLE has just one bit set, so both tests would do the same thing. But the adjacent IMPORTED_ALL mask has several, and using the more general form is safer if IMPORTED_CLOSEABLE ever has multiple bits, or this code gets copy/pasted elsewhere or something.
Tue, Apr 23
(This seems stable now, and there's no specific action here.)
- Typo fix.
One note here is that HeraldPreCommitContentAdapter has some similar logic, although it's more low-level.
The "how do we store this data" question kind of relates back to T13056. This is a case where we have edge-like data (Commit Has Related Revision) but we also have metadata (why the two are associated). This currently isn't stored as edge data, but a possibly cleaner approach would be:
The reproduction case for this may be "have a ref which is an annotated tag". Let me see if that works.
There's not much of a wire-proto.c to reference. Here's the code that generates the entire thing we're parsing (in Git 2.21-rc1):
In PHI1008, when commit X reverts commit Y, we don't write a revert edge between X and revisions associated with Y. We should.
Mon, Apr 22
Leaving the "Assign To: [...]" field blank will remove assignees, but this is not obvious:
Fri, Apr 19
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: