Why Is Differential Better?
ActivePublic
Actions

Authored by avivey on Jul 20 2015, 6:16 PM.

Tags

None

Referenced Files

	F642615: Why Is Differential Better?
	Jul 20 2015, 6:16 PM

Subscribers

None

Tokens

"Mountain of Wealth" token, awarded by michaeljs1990.

	Differential is the code review application.

	Quick Comparison
	-----

	<table>
	<tr>
	<th>Action</th>
	<th>GitHub</th>
	<th>Gerrit</th>
	<th>Differential</th>
	</tr>
	<tr>
	<td>Submit change for review</td>
	<td>Make N commits; Push branch; Create PR from UI.</td>
	<td>Make exactly one commit for each review; Push to magic branch; Add reviewers from UI.</td>
	<td>Make N local commits; `arc diff` uploads all changes as a single Revision (change). Add reviewers from CLI or UI or automatically.</td>
	</tr>
	<tr><td>Pre-review execution</th>
	<td>N/A</td>
	<td>N/A</td>
	<td>Can run custom lint and unit tests before uploading diff</td>
	</tr>
	<tr>
	<td>Review change </td>
	<td>No formal state; Only allows comments</td>
	<td>+/-1s.</td>
	<td>Formal "Requires changes"/"Requires Review"/"Accepted" states. Can require specific persons/teams to approve.
	Comments have explicit Done checkbox.</td>
	</tr>
	<tr>
	<td>Update Change</td>
	<td>Add more commits and push to branch OR amend and force-push</td>
	<td>Amend commit, push to magic branch. Commit message overwrites description.</td>
	<td>Do whichever you like; `arc diff` will upload content of change only. All metadata kept.</td>
	</tr>
	<tr>
	<td>Inter-revision Compare</td>
	<td>Hard to get to</td>
	<td>Easy</td>
	<td>Easy</td>
	</tr>
	<tr>
	<td>Update Change Description</td>
	<td>N/A: PR description is not kept</td>
	<td>Considered a new patch-set; Forgets previous +/-1s.</td>
	<td>A different kind of transaction; State kept.</td>
	</tr>
	<tr>
	<td>Rebase Change </td>
	<td>Solve conflicts during merge</td>
	<td>Automatic rebase from UI, requires new review.</td>
	<td>Automatic rebase while submitting if possible; Manual otherwise (Remembers state).</td>
	</tr>
	<tr>
	<td> Merge reviewed change </td>
	<td>Merge button. Create superfluous merge commit.</td>
	<td>Pushes commit in web UI</td>
	<td>Creates commit from revision in web UI.</td>
	</tr>

	<tr>
	<td>JIRA integration</td>
	<td>One way link (JIRA{icon long-arrow-right}review)</td>
	<td>One way link (JIRA{icon long-arrow-right}review)</td>
	<td>Two way link</td>
	</tr>

	<tr>
	<td>Dependency between changes</td>
	<td>Not supported</td>
	<td>Explicit, via Git commits</td>
	<td>Explicit, external to Git</td>
	</tr>


	<tr><td>
	results - Commits vs Change </td>
	<td>All interim commits + empty Merge commit in the logs. Link to PR only parsed in GH. Branch needs to be removed</td>
	<td>A single commit. Link to review is a hash that is only usable via search. </td>
	<td>A single commit. Link to review in plain text. Reviewers, summary, test plan and tickets are explicitly written in the commit message.</td>
	</tr>

	<tr><td>push permissions</td>
	<td>Can limit read/write to persons to repository</td>
	<td>Can limit read/write to persons per branch</td>
	<td>Can limit read/write to persons; Supports advanced rules to prevent commits based on content, user, branch, and review status.</td>
	</tr>
	</table>



	Advantages:
	------
	- Traceability and audit trail: The commit log / blame log contains a link to each review made, exposing the discussions.
	- Commit message is generated from the revision details, which may be edited (Before committing) from the UI.
	- When submitting a revision, there's a structured form, with fields for Description, Test Plan, and Tickets (etc). This forces users to create the data, and allows for searching through later.
	- Can provide more granular control on commits (via [[/herald/ \| Herald]]).
	- Provides a pipeline for linting code before a review; Lints can warn about common errors before human intervention.
	- Decouples local commits from "master" commits; Local changes can be in small/messy commits, final change contains a single coherent change.
	- Avoids polluting the global space with short-lived branches (//GitHub//).
	- Entire change in a single page (//Gerrit//).
	- More about revisions upstream: [[ https://secure.phabricator.com/book/phabflavor/article/recommendations_on_revision_control/ \| Recommendations on Revision Control]] and [[ https://secure.phabricator.com/book/phabflavor/article/writing_reviewable_code/ \| Writing Reviewable Code]].
	- And at http://cramer.io/2014/05/03/on-pull-requests/
	- Own the code: Installs are expected to make changes to the tool's code, to fit their needs. The code is very modular and clean (Even though it's PHP).

Event Timeline

phriction page comparing differential with gerrit and github. Not automatically applicable to every installation, but can be a reasonable start for your presentation.

michaeljs1990 awarded a token.Jul 20 2015, 6:50 PM

Why Is Differential Better?ActivePublicActions

Event Timeline

Why Is Differential Better?
ActivePublic
Actions