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:

Trying to reproduce this locally just hits the ft_doc.epochModified issue. I'm not immediately sure why the behavior differs between my local install and secure, but that issue probably needs to be fixed first.

Actually, I'm not entirely right in merging that task -- T13163 isn't quite the same as the other two issues here. I think they're similar, but the query text is relevant in the case of T13163. Notably:

Thanks!

• Trivial update mostly for demonstrating API calls.

PHI781 asks for [ ] Show on commit message template. for "Maniphest Tasks:".

(Does this survive a cert file with no terminal newline?)

See https://secure.phabricator.com/book/phabricator/article/tone/

How much faster does this run with --quiet? How does ./bin/repository rebuild-identities > /dev/null compare to --quiet?

(We could expose it in some sort of unstable.do-not-trust-this-value field but then I suspect everyone would use that field and complain when it proved unstable and not trustworthy.)

We intentionally don't do that because many type fields are internally some string like core.custom:std:transaction/epriestley-tmp.v2:!!:bugfix or similar. Not quite that bad, but nonsensical or otherwise not the best values for API consumers (inconsistent; namespaced in an unhelpful way; old names waiting for migration, etc). For example, the actual getTransactionType() value here is core.create, but there's no real value in exposing the core.<...> part over the API.

Commits and Phriction wiki pages currently don't get a "create" transaction, since the "create" transaction is built by EditEngine and these objects don't create via EditEngine at the moment.