Page MenuHomePhabricator

"Close Revision" and "Merge Task" interactions should be real transactions, not comments
Closed, ResolvedPublic


Below is an example email. This email tells people that the diff is closed, but why does it say "xxx added a comment"? This is confusing. We sometimes get emails about "xxx accepted this diff" and also it says "xxx added a comment". Can we remove sentences like that when there is actually no human-produced comment?

---------- Forwarded message ----------
From: xxx <>
Date: Wed, Aug 13, 2014 at 10:05 AM
Subject: [Differential] [Closed] Dx777: FOO-BAR

xxx closed this revision.

xxx updated this revision to Diff 2449.

xxx added a comment.

Closed by commit rSomethinghere (authored by xxx).


  rS Something





Related Objects


Event Timeline

sweetcircle assigned this task to epriestley.
sweetcircle raised the priority of this task from to Needs Triage.
sweetcircle updated the task description. (Show Details)
sweetcircle added a subscriber: sweetcircle.

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.

epriestley renamed this task from Confusing "xxx added a comment"email actually has no comments to "Close Revision" and "Merge Task" interactions should be real transactions, not comments.Aug 13 2014, 8:01 PM
epriestley triaged this task as Normal priority.
epriestley updated the task description. (Show Details)
epriestley added a project: Transactions.
epriestley added a subtask: Restricted Maniphest Task.
epriestley reassigned this task from epriestley to btrahan.Aug 20 2014, 8:08 PM

The "merged tasks" half of this is easy:

  • When you merge two tasks, we represent the merge as comments on each task, instead of as real transactions.
  • Specifically, in PhabricatorSearchAttachController, we add comments for "Merged into: ..." and "Merged tasks: ...".
  • Instead, add new transaction types for each half of the merge and apply the real transactions instead.
  • Then massage the rendering until it looks reasonable and maybe give them pretty icons.
  • Test by merging tasks and making sure both halves look OK.

The "closed by commit" half is sort of easy but sort of not:

  • On the face of it, same issue.
  • However, we put a lot more information in the comment right now, and would like to put even more (T3686).
  • I think the ideal case is that we shove all the information we need into the transaction newValue or metadata, and then maybe have a popup? So the transaction reads like this:
epriestley closed this revision with commit rXnnnnn (authored by alincoln). __Explain Why__

And then maybe that's a popup with "the tree hash matched this other tree hash yada yada" I guess? There's already a way to render the link that Herald uses to render a link to transcripts. Then this would fully resolve T3686.

But getting halfway there would be helpful too. Not sure how much of a mess this is.

(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.

btrahan closed subtask Restricted Maniphest Task as Resolved.Oct 16 2014, 5:09 PM