git: e006b6a2c1b9 - stable/12 - MFC 376479200760: Fix whitespace in mlx5en(4).

Kyle Evans kevans at freebsd.org
Fri Jan 22 14:26:22 UTC 2021


On Fri, Jan 22, 2021 at 8:19 AM Hans Petter Selasky <hps at selasky.org> wrote:
>
> On 1/22/21 2:59 PM, Kyle Evans wrote:
> > For the record, as per [0], these should have been cherry-picked using
> > -x which adds a " (cherry picked from commit ...)" annotation at the
> > bottom. With the annotation in place, the leading MFC line can be
> > dropped and the original message otherwise preserved (dropping any
> > metadata at the bottom that makes sense, e.g. "MFC after" tags). The
> > -x line helps at least the MFC tracker match the commit from main.
> >
> > Thanks,
> >
> > Kyle Evans
> >
> > [0]https://github.com/bsdimp/freebsd-git-docs/blob/main/MFC.md
>
> Hi Kyle,
>
> Shouldn't the committers-guide be updated to reflect this is now the
> official way to do it?
>
> https://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/
>

The committers guide wasn't going to be updated with the contents of
Warner's freebsd-git-docs until the doc switch to a less arcane
format.

> I see no problem keeping MFC at the beginning of commit e-mails. Makes
> it easier to sort, and it is backwards compatible!
>
> MFC rXXXXX refers to a SVN commit.
> MFC [0-9 A-F] indicate a GIT commit.
>
> BTW: When MFC-ing a commit which was done using SVN, should we use MFC r
>   or refer to the git hash?
>

I can see a good argument for wanting to record the svn revision
number where that's relevant, but I'd propose not prepending MFC when
cherry-picking any git-originating commits so that oneline/shortlog or
whatever it's called is as usable on stable as it is on main going
forward.

To be clear, I think the recommendation should be to:

1.) Use cherry-pick -x regardless so that the MFC tooling doesn't need
to grok both going forward, and
2.) Optionally prepend an "MFC rXXXXXX" if it came from svn

Thanks,

Kyle Evans


More information about the dev-commits-src-all mailing list