svn primer translation to git

Ed Maste emaste at freebsd.org
Thu Jun 25 12:55:26 UTC 2020


On Thu, 25 Jun 2020 at 03:09, Kristof Provost <kp at freebsd.org> wrote:
>
> The original commit already followed the ‘headline summary, expanded body’ rule. This MFC would also work (often there’s no blank line between the ‘MFC’ and the next line), but I do wonder if MFC r362183: netmap: vtnet: fix races in vtnet_netmap_reg() wouldn’t be better.

I agree we need to choose and document an approach.

There are examples of your proposed style already. I would suggest we
go one step further though; the source revision is really metadata,
and ought to be tracked by the tools in an automated or semi-automated
way. The git equivalent for MFCs is `git cherry-pick`, and it has a -x
flag to append the original commit hash.

Let's say I wanted to MFC r362543 (91285bbdc146 in the current GitHub mirror):

```
commit 91285bbdc146fee00b83b8605e11aec19ed18b2a
Author: emaste <emaste at FreeBSD.org>
Date:   Tue Jun 23 15:36:05 2020 +0000

    ldconfig: remove i386 aout invocation

    aout support in ldconfig hasn't been required since FreeBSD 2.x.

    Anyone still using FreeBSD 2 shared libraries can use a FreeBSD 2
    ldconfig to generate aout ldconfig hints.

    Reviewed by:    dim, kib
    Sponsored by:   The FreeBSD Foundation
    Differential Revision:  https://reviews.freebsd.org/D24883

Notes:
    svn path=/head/; revision=362543
```

To MFC this to a stable/12 worktree I could use
```
% git cherry-pick -x 91285bbdc146
```

When I go to commit the default commit message is:
```
ldconfig: remove i386 aout invocation

aout support in ldconfig hasn't been required since FreeBSD 2.x.

Anyone still using FreeBSD 2 shared libraries can use a FreeBSD 2
ldconfig to generate aout ldconfig hints.

Reviewed by:    dim, kib
Sponsored by:   The FreeBSD Foundation
Differential Revision:  https://reviews.freebsd.org/D24883

(cherry picked from commit 91285bbdc146fee00b83b8605e11aec19ed18b2a)

# Conflicts:
#       libexec/rc/rc.d/ldconfig
```

I think this is fine, and consistency will facilitate tooling for
automating to answer questions like "what commits of mine have not
been merged to stable/12 yet?" (If I wrote git I'd choose a different
format for the message, but consistency is more important than
aesthetics here).


More information about the freebsd-git mailing list