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

From: Paul Smith <paul@mad-scientist.net>
Date: Dec 30, 2019, 15:15 UTC
Message-ID: <85e17e0628e05279d1dbbe62b877caa90a43ec38.camel@mad-scientist.net>
In-Reply-To: <CAEW0o+gtya5tm6Wb474Srmb2j4E9ocm9p75=aZWjTASbApsb1A@mail.gmail.com>

On Mon, 2019-12-30 at 12:59 +0100, Arnaud Bertrand wrote:

Show 9 quoted lines

> > 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.