Page MenuHomePhabricator
Create Task
Maniphest T10914

Allow arcanist to use immutable or mutable history on a branch by branch basis
Closed, DuplicatePublic
Actions

Description

Root problem:

We use two distinct workflows with git / arc.

  1. I am implementing a change by myself, that will resolve to a single commit, I can re-write history all I want, because I have no collaborators.
  2. I am implementing a change where the branch is shared by two or more colleagues for a longer lived period. Re-writing commits that I have shared with other people is a big no-no.

Now arcanist can support both of these flows, by setting immutable or mutable for the history. What there doesn't seem to be is support for rules like unto what is available for selecting commit ranges. If I edit the .arcconfig file I can't ignore that change and land it, unless I make the file _completely_ ignore by git.

Now the second flow is far rarer. We can just make a branch and skip arc, but then we lose out on review via differential (we also use it to trigger CI, but that's easily enough changed). It's not the end of the world, but it would be great to be able to say use immutable history when the branch prefix is shared/* and mutable otherwise or something like that.

Related Objects

Event Timeline

benjumanji created this task.May 3 2016, 4:12 PM
benjumanji updated the task description. (Show Details)
chad added a subscriber: chad.May 3 2016, 4:15 PM

We can just make a branch and skip arc, but then we lose out on review via differential

We plan to support reviewing a pushed branch in Differential, would that resolve the problem? See T5000

benjumanji added a comment.May 3 2016, 4:17 PM

That would work for us, yes.

epriestley added a subscriber: epriestley.May 3 2016, 4:26 PM

See also T10691.

You can also make an initial commit on shared/whatever to modify .arcconfig and change the rule for that branch, just remember to discard the change when you merge.

A variant of (2) which works more naturally with Phabricator is to review each change to the shared branch and then land it to the shared branch, so only reviewed code is published. This is how we develop on the rare occasion that we cut long-lived feature branches. No un-reviewed commits are published, and no published commits are rewritten. See also: https://secure.phabricator.com/phame/post/view/766/write_review_merge_publish_phabricator_review_workflow/

benjumanji added a comment.May 3 2016, 4:41 PM

Yeah, I'd like to encourage people to work like that (review each change to the shared branch and then land it to the shared branch) but just getting people to use arc "normally" is proving more than some people can bear (I recently pushed a us onto git from svn, the transition has not been without pain for some). I hadn't considering commiting then reverting the change to .arcconfig.

I'd be happy for this to get merged into T5000: Using Differential with plain Git, without requiring Arc.

Thanks for your input as always.

epriestley added a comment.May 3 2016, 4:49 PM

Cool. I'll merge this into T5000, then -- beyond the mechanics discussed there, that's broadly the "provide smoother onboarding workflows so you can use Phabricator more gradually" task.

epriestley closed this task as a duplicate of T5000: Using Differential with plain Git, without requiring Arc.May 3 2016, 4:49 PM
Phabricator · Built by Phacility