git: 73c14cc76b5f - main - Remove history.immutable from .arcconfig

[Mark Johnston]

On Tue, Apr 13, 2021 at 01:53:07PM -0600, Warner Losh wrote:
> On Tue, Apr 13, 2021 at 9:23 AM John Baldwin <jhb at freebsd.org> wrote:
> 
> > On 4/13/21 4:38 AM, Alex Richardson wrote:
> > > The branch main has been updated by arichardson:
> > >
> > > URL:
> > https://cgit.FreeBSD.org/src/commit/?id=73c14cc76b5f815c6b1bd93089ebafdd9269d343
> > >
> > > commit 73c14cc76b5f815c6b1bd93089ebafdd9269d343
> > > Author:     Alex Richardson <arichardson at FreeBSD.org>
> > > AuthorDate: 2021-04-13 11:36:24 +0000
> > > Commit:     Alex Richardson <arichardson at FreeBSD.org>
> > > CommitDate: 2021-04-13 11:36:25 +0000
> > >
> > >      Remove history.immutable from .arcconfig
> > >
> > >      The `history.immutable` setting prevents arcanist from updating
> > >      the commit messages with the Differential URL and therefore
> > >      makes updating patches awkward with a rebase workflow.
> > >
> > >      In case this new behaviour is not wanted the old one can be restored
> > >      by running `arc set-config --local history.immutable true`.
> > >
> > >      Test Plan: `arc diff --create HEAD^` adds the metadata now.
> > >
> > >      Reviewed By:    #phabric-admin, imp, lwhsu
> > >      Differential Revision: https://reviews.freebsd.org/D27971
> >
> > FYI, this might break git arc since arc will now start rewriting commits
> > rather than leaving them alone.

Empirically, arc does not do this when git-arc is used.  One of the
options passed to arc diff --create apparently inhibits that behaviour,
though I'm having trouble figuring out exactly why from reading the
arcanist sources.

> > If so, we can look use 'arc diff'
> > with --head to turn off some of its magic.  It would also avoid having
> > 'git arc' have to adjust the working copy.
> >
> 
> I'd honestly rather have 'git arc create' stamp this in from the git go.
> I really dislike having it not there until just before I go to commit.

This is pretty easy to do if the commit is currently checked out.  The
question is what we should do when uploading a series of patches.
Rewriting history would make child branches stale, so one would have to
go through them and manually rebase --onto the rewritten branch.  I'm
not sure if this is a problem for most developers.  In general it seems
there is a preference for rewriting history to add reviewers and
differential revision tags over the current approach, which avoids
rewriting history.