In my case (using GMail) it appears to thread properly as well however apparently some clients (KMail) rely on these headers more heavily than others.

In order for threading to work in email clients, the Message-ID header needs to be set on the initial email, with following emails having In-Reply-To / References set to that same Message-ID.

I can't reproduce this: mail threads properly in my client.

• D19634 allows reviewers to mark their own inlines as "Done" before they submit them. This addresses the case where you want to leave a non-actionable inline (like "This is much-improved.") but feel like leaving an inline like this is imposing on the author because they "must" check it off.
• D19635 marks the author's own inlines as "Done" by default. They may un-mark them if they prefer (e.g., actually want to leave themselves a TODO). This addresses the case where authors feel like they "must" check off every comment, so they either reply in two passes (one to submit; one to check off all their own replies) or avoid replying.

@bgamari Did you ever find a solution?

This is also showing up in initial email, which is silly and pointless.

I believe this was fixed by D17558 and discussed in T11050.

I've marked D19541 as resolving this. The change there isn't quite what was asked for here, but overlaps significantly.

T1022 is possibly somewhat-vaguely-adjacent on symlink stuff.

@jcox do you know how to reproduce arc diff dying when you try to create certain types of diffs that move or remove symlinks? I think that's adjacent, if not identical to what's being talked about here.

As a special case of this, if you commit an empty a.py file, then add content to it and also add a new empty b.py file in a commit on top of it, the new empty b.py will be detected as a copy of a.py based on the previous (empty) content of the file. I think Git is being pretty reasonable/consistent here, but this is potentially also expectation-defying:

D19442 is marked as fixing this, although it just raises the limit from 80 to 100. This span measures the number of characters between the first changed character and the last changed character (not the total number of characters on the line) and we haven't seen tons of interest in this over the last several years so I think few installs are running into issues with it even at 80. Bumping it to 100 should give us a bit more breathing room but I don't currently plan to make it configurable (see T8227).