Re: A little report on informal commit tag usage

Hi,

On 2019-07-16 10:33:06 -0400, Tom Lane wrote:
> Michael Paquier <michael(at)paquier(dot)xyz> writes:
> > As mentioned on different threads, "Discussion" is the only one we had
> > a strong agreement with. Could it be possible to consider things like
> > Author, Reported-by, Reviewed-by or Backpatch-through for example and
> > extend to that? The first three ones are useful for parsing the
> > commit logs. The fourth one is handy so as there is no need to look
> > at a full log tree with git log --graph or such, which is something I
> > do from time to time to guess down to where a fix has been applied (I
> > tend to avoid git_changelog).
>
> FWIW, I'm one of the people who prefer prose for this. The backpatching
> bit is a good example of why, because my log messages typically don't
> just say "backpatch to 9.6" but something about why that was the cutoff.

They don't preclude each other though. E.g. it'd be sensible to have both

> Per gripe from Ken Tanzer. Back-patch to 9.6. The issue exists
> further back, but before 9.6 the code looks very different and it
> doesn't actually know whether the "var" name matches anything,
> so I desisted from trying to fix it.

and "Backpatch: 9.6-" or such.

> I am in favor of trying to consistently mention that a patch is being
> back-patched, rather than expecting people to rely on git metadata
> to find that out. But I don't see that a rigid "Backpatch" tag format
> makes anything easier there. If you need to know that mechanically,
> git_changelog is way more reliable.

I find it useful to have a quick place to scan in a commit message. It's
a lot quicker to focus on the last few lines with tags, and see a
'Backpatch: 9.6-' than to parse a potentially long commit message. If
I'm then still interested in the commit, I'll then read the commit.

Greetings,

Andres Freund