The reason it does this is because "Closed by commit rSomethinghere (authored by xxx)." is technically a comment. For historical reasons, this was implemented in a silly/easy way and hasn't been fixed yet. We should fix it.

Yay! Thanks @epriestley!

(Neither of these transaction types needs to actually do anything when applied, it's fine to leave the logic outside of the transaction engines.)

Been working on this...

One question, for the "the tree hash matched this other tree hash yada yada" how do I get said tree hashes? Or maybe said differently, its not clear to me how that tree hashing bit happens, so I am not sure how to properly save what matched what to render later...

One design detail - I have this mostly done with a brand new transaction for "closed by commit" with newValue containing the good stuff BUT I am now thinking it should not be a new transaction and instead just be TYPE_ACTION with the metadataValue getting updated. This is mainly so that we don't have weird transaction rendering. I plan to pursue this TYPE_ACTION version so yell at me if that sounds really bad.

You might know half of this already, but here's the general overview:

The tree hashes come from Git. Each commit has a "commit hash" and a "tree hash", and you can show the tree hashes with git log --format=%T. Basically they're a hash of all the files/directories at a commit, but not the commit message or commit metadata. So the computation is roughly:

• tree hash = HASH(all the files and directories)
• commit hash = HASH(tree hash + commit message + author + committer + commit date)

The important bit is that the tree hash remains stable after an --amend, while the commit hash changes.

When you arc diff, we send up zero or more hashes for each commit. Under SVN, we send no hashes; under Mercurial we send up a commit hash for each commit (there are no tree hashes in Mercurial); under Git we send up both the tree and commit hash for each commit.

You can see the commit and tree hash in Differential for a Git commit, in the Local Commits table:

This stuff is stored in the differential_revisionhash table and looks something like <"gttr", "the-tree-hash">, <"gtcm", "the-commit-hash">. Those constants are defined somewhere.

When we go to figure out which revision a commit corresponds to, we compute the same zero-or-more hashes (basically, by running git log --format=%H %T on the commit we just discovered) and then looking up the hashes in the table. Specifically, this happens in DiffusionLowLevelCommitFieldsQuery->executeQuery(): if we can't figure out the revision from the commit message, we go fishing with hashes.

I plan to pursue this TYPE_ACTION version so yell at me if that sounds really bad.

That sounds good to me. Agreed on your reasoning.

(The reason we do all that is that it lets us get it right when someone -- maybe arc -- has changed the commit message without changing the commit content.)

The important bit is that the tree hash remains stable after an --amend, while the commit hash changes.

For posterity, I'm slightly wrong here -- this is only true if the --amend changes the commit message without changing the actual diff. This is true of automatic --amends that arc performs, but not true of --amends in the general case.