Arcanist's history.immutable

[Andrew McCann]

So, this is less of an issue than I thought.

It turns out I had a bit of a misunderstanding of this feature. I'll share
in the case others did as well.

The history.immutable setting only controls the default behaviour of 'arc
land'.  I was under the impression earlier that the setting was absolute.

If you are landing a feature branch, and wish to avoid the merge commit and
commit history on that branch, use 'arc land --squash' to create one single
commit.

If you're in a situation like Andreas mentioned where there is value in the
history, you can (currently) just use the default behaviour. If you prefer
to be explicit and not depend on the default setting, I believe you can use
'arc land --merge'

-Andrew



On Sun, Nov 1, 2015 at 7:37 AM, Kevin Funk <kfunk at kde.org> wrote:

> On Saturday, October 31, 2015 05:26:47 PM Andrew McCann 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).
>
> I was copying the .arcconfig from another repository to
> kdevplatform/kdevelop/
> etc.. To be honest, at that time I thought 'history.immutable' was
> referring
> to history-rewriting in Git, so I thought it's fine.
>
> But after reading above link I'd lean towards removing that line, i.e.
> making
> it 'false'. I dislike having merge-commits for every single change we do
> via
> 'arc land'. It's also more like it has been in reviewboard times.
>
> So in my opinion: Let's remove it.
>
> PS: All the other repos in KDE seem to have 'history.immutable' set to
> true as
> well. Not sure if it's intentional or just c&p'ed around.
>
> Maybe Aleix  can ask around (in his office?) what the other opinions of KDE
> people are?
>
> Cheers,
> Kevin
>
> > 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
>
> --
> Kevin Funk | kfunk at kde.org | http://kfunk.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20151112/c586f6e1/attachment-0001.html>