Arcanist's history.immutable

[Aleix Pol]

On Sun, Nov 1, 2015 at 1:26 AM, Andrew McCann <amccann at gmail.com> wrote:
> Hi all,
>
> First, as a new member, it's good to contribute. I've been a user of
> KDevelop for many years. I am now working to get things working well on OSX.
>
> For develop & kdevplatform repositories Arcanist is currently configured to
> commit all 'feature branch' history when 'arc land' is used. When I used the
> arcanist tool aka 'arc' to commit my most recent diffs it had the surprising
> effect of committing all of the history of the 'feature branch' as well.
> This was unexpected behaviour to me, as my previous use of arcanist has not
> had this behaviour. I'm of the mind that public history should be somewhat
> clean, with each commit being a logical change (when possible).
>
> Apparently this behaviour is not the default behaviour and was configured by
> adding the "history.immutable" : true configuration to ".arcconfig" in the
> repository root.  This setting is about controlling the arc workflow, and
> specifically how feature branches are landed. You can read more about this
> setting here:
> https://secure.phabricator.com/book/phabricator/article/arcanist_new_project/
>
> This was intentionally configured, so clearly someone gave it some thought.
> I just wondered what the ongoing thoughts are on the use of 'arc land'
> With the immutable history setting, 'arc land' will make at least 2 commits
> for every 'arc land'. (one for the feature diff, one for the merge).
>
> To be clear, I'm not talking about rewriting history of public repository.
> Just how the commit history that is generated when working on a given 'diff'
> in the arcanist workflow. Often there are multiple commits given the code
> review process.
>
> My personal preference is to keep public history clean, and have just one
> commit in the public repository per landed "differential".  One can
> accomplish this now by manually making commits. However, this largely undoes
> some of the convenience of arcanist.
>
> Seems the choices are:
>    1) Don't use arcanist to land changes, manually squash change sets /
> feature branches, and keep a 'clean' public history.
>    2) Use arcanist, accept multiple-commits per "land"
>    3) Use arcanist, configure to mutate history for 'land"
>
>
> I am happy to work with any option.
>
> -Andrew

Hi Andrew,
Thanks for your e-mail.

Phabricator, we're just adopting the project and the first steps are
always the complex ones. Additionally, this wasn't set up by us, but
by the sysadmin team. I'm not sure where it came from though. I'd say
we just need a conclusion there and then take it to them, to see how
to figure this out.

Regarding history and patch submission, I liked how it worked with
reviewboard. I don't really mind multi-commit (although I rather not,
especially when there's style issues). I would much prefer if we
didn't get a merge commit as well.

Aleix