Arcanist's history.immutable

Andreas Pakulat apaku at gmx.de
Sun Nov 1 08:36:26 UTC 2015


Hi,

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 agree on the 'clean' history, but my definition of the word is likely
different from yours. That is the history of the feature branch should not
contain any commits that merely make the code compile or fix code-style
isues. However I like it if certain conscious decisions are documented as a
commit. For example if the feature works fine but it turns out during
testing that its not very efficient it would be nice to have a separate
commit that improves the efficiency. Or similarly if a particular problem
arises that only affects a certain 'environment' (like a particular type of
machine setup, or a particular type of data), then a separate commit
documenting the fix would be good. Sometimes these things are only
discovered after landing the branch, but sometimes they're not.

So personally I usually cleanup the history via git rebase first and then
land that and like to land it with immutable history so that arc land
creates a merge commit. (using phabricator at work)

Unlike Aleix I also like the merge commit from arc land as that gives (more
or less) a single point for when the feature was introduced. A merge commit
may also make git bisect a bit faster as a whole branch may possibly be
excluded from the bisecting.

Just my 2 cents as someone using phabricator for a while already (though
possibly not as extensively as people here will be using it)

Andreas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20151101/8b810c05/attachment.html>


More information about the KDevelop-devel mailing list