git: 072b13ec97 - configure arcanist for the git world

[Eitan Adler]

On Mon, 14 Dec 2020 at 11:07, John Baldwin <jhb at freebsd.org> wrote:
>
> On 12/13/20 8:52 AM, Eitan Adler wrote:
> > The branch main has been updated by eadler:
> >
> > URL: https://cgit.FreeBSD.org/doc/commit/?id=072b13ec97b32d91379f5c11e577d3509af00e18
> >
> > commit 072b13ec97b32d91379f5c11e577d3509af00e18
> > Author:     Eitan Adler <eadler at FreeBSD.org>
> > AuthorDate: 2020-12-13 16:52:31 +0000
> > Commit:     Eitan Adler <eadler at FreeBSD.org>
> > CommitDate: 2020-12-13 16:52:31 +0000
> >
> >     configure arcanist for the git world
> >
> >     Problem
> >
> >     The documentation ("doc") repository has been converted to git but
> >     arcanist does not yet understand how to interact with phabricator in
> >     this world.
>
> The callsign is still needed for folks who make a private clone and do work
> in branches of that.  For example, my workflow in src post-conversion will
> still consist of branches off of github.com/bsdjhb/*.git that are then
> pushed into arc and only pushed up to the actual upstream after review.

This should not be required as long as you have the true origin as one
of the remotes. I _explicitly_ tested this case.  If this isn't
working can you please run `arc which` on the broken case?

>
> >     Solution
> >
> >     - remove the callsign "D" which should be inferable from having one of
> >       the cgit URLs as a remote
> >     - remove "history.immutable" which was a workflow only required for
> >       subversion
>
> I don't know that we want all of the arcanist-formatted data in our commit
> logs.  Adding the DR URL automatically might be welcome, but I don't know
> that we want arcanist's format for Reviewers, Reviewed By, etc

Agreed: though there are tradeoffs here. history.immutable=true has
several other implications which go against our workflow. Specifically
it will result in `arc land` using merge commits instead of squash
commits Please see
https://secure.phabricator.com/book/phabricator/article/arcanist_new_project/#history-mutability
for details.

>   At the very
> least it probably warrants wider discussion?

+1: I'll try and start the conversation soon.

At a high level we have a couple of options though:

- forking arcanist to provide a specific template
- amending the template post-commit (what I tend to do anyways)
- using history.immutable=true
- switching to using arcanist's format












-- 
Eitan Adler
Source, Ports, Doc committer
Bugmeister, Ports Security teams