Page MenuHomePhabricator

Base git hash should be displayed on Differential.
Closed, ResolvedPublic

Description

Our company has many different git branches other than master. Every time someone uploads a diff, we don't know what git HASH it is actually diffing against. It would be extremely helpful if arc uploads the current git hash info alongside the Branch+Arcanist Project information (and the hash be a link).

Event Timeline

chang888 renamed this task from Mr to Base git hash should be displayed on Differential..
chang888 assigned this task to epriestley.
chang888 raised the priority of this task from to Normal.
chang888 updated the task description. (Show Details)
chang888 added a project: Phabricator.
chang888 added a subscriber: chang888.

This should be shown in the "Base" column of the diff table, but we could do a better job about linking it.

Screen_Shot_2014-03-11_at_12.58.23_PM.png (276×1 px, 51 KB)

Ah I see it now thanks for pointing that out.

BTW how difficult is it to show which branch we landed on? That is also very helpful to have.

What do you imagine the UI looking like? A revision can be associated with arbitrarily many commits, and each commit can be on arbitrarily many branches, so there's no simple "Landed To: master" answer.

So a very common problem that is happening in my company is that people do a "arc diff origin/<name-of-remote-branch>" and then the reviewer is confused as to whether the review is done against origin/master or origin/live or origin/<something-else>. The current UI only shows the branch name of the local branch.

A very helpful information to have for our particular workflow (which is, only diffing against one branch at a time), is to show what the person is diff'ing against (e.g. "Diff Against: origin/live-v029").

epriestley added a subscriber: epriestley.

Low priority, but a couple of quick feature improvements here that will make Differential nicer and move us closer to mobile:

  1. Use more modern UI elements in the "Local Commits" table, like D8504 did for the "Revision Update History" table.
  2. In both tables, use DiffusionCommitQuery to try to look up all the commit hashes before we render the tables and see if they correspond to commits we know about already. For hashes we know about, link them to Diffusion.