On Tue, Apr 13, 2021 at 01:53:07PM -0600, Warner Losh wrote: > On Tue, Apr 13, 2021 at 9:23 AM John Baldwin <j...@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 <arichard...@freebsd.org> > > > AuthorDate: 2021-04-13 11:36:24 +0000 > > > Commit: Alex Richardson <arichard...@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. _______________________________________________ dev-commits-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all To unsubscribe, send any mail to "dev-commits-src-all-unsubscr...@freebsd.org"
