Re: Feature request: add a metadata in the commit: the "commited in branch" information

[Paul Smith <paul@mad-scientist.net>]

On Mon, 2019-12-30 at 12:59 +0100, Arnaud Bertrand wrote:
> > Why does it need to be the branch name?  You can add your own extra
> > metadata to the git description.
> 
> That's typically my problem.  It is not possible "by default", I mean
> - It is only possible if the developer configure something
> - or if there is an upper layer that guarantee this
> By default, there is no hook embedded with the clone. So, as far as I
> know (and I hope I'm wrong!), you have to use upper layer tools or to
> change environment variables to activate this feature.

In general I have found that trying to mandate what users do in their own
repositories on their own systems is a losing proposition.

Instead, we put requirements on what content is pushed to the central
repository.  Because the central repository is managed by the SCM admin
team we always know only properly-constructed commits can appear there,
without having to assume that every individual developer's local
environment has been set up in a specific way.

This can be done with hooks in the central repository: there are Git hooks
that are run before any push is accepted, which can cause the push to be
rejected, and hooks that are run after a push is accepted, which can be
used for triggering other operations.

So if you have a requirement about contents of Git commit message format,
for example, you can enforce that via these hooks.  If someone attempts to
push commits to the central repository and the commit message has an
incorrect format then the push is rejected and they'll have to fix it
before they can proceed to push.

In the environments I've been associated with we don't care about branch
names; instead everything is based on bug tracker identifiers.  Every
commit needs to be associated with a valid bug ID (added to the commit
message) and the pre-push hook verifies this and rejects the commit if not.
Then after the push is accepted, post-push hooks will update the bug
tracker with information about the push (SHA, software version, etc.)  This
ensures that development and management can use the bug tracker as their
primary planning tool to know what has been accomplished and what is left
to accomplish.  Since the commit message is persisted through cherry-picks, 
etc. it allows us to know which bugs were fixed in which different patch
release branches as well.