Arcanist's history.immutable

Andrew McCann amccann at gmail.com
Sun Nov 1 00:26:47 UTC 2015


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20151031/f9e9c3ec/attachment.html>


More information about the KDevelop-devel mailing list