Re: Recording the current branch on each commit?

[Sitaram Chamarty <sitaramc@gmail.com>]

On 04/28/2014 01:03 AM, Johan Herland wrote:
> On Sun, Apr 27, 2014 at 7:38 PM, Jeremy Morton <admin@game-point.net> wrote:
>> On 27/04/2014 10:09, Johan Herland wrote:
>>> On Sun, Apr 27, 2014 at 1:56 AM, Jeremy Morton<admin@game-point.net>
>>> wrote:
>>>> Currently, git records a checksum, author, commit date/time, and commit
>>>> message with every commit (as get be seen from 'git log').  I think it
>>>> would
>>>> be useful if, along with the Author and Date, git recorded the name of
>>>> the
>>>> current branch on each commit.
>>>
>>> This has been discussed multiple times in the past. One example here:
>>> http://thread.gmane.org/gmane.comp.version-control.git/229422
>>>
>>> I believe the current conclusion (if any) is that encoding such
>>> information as a _structural_ part of the commit object is not useful.
>>> See the old thread(s) for the actual pro/con arguments.
>>
>> As far as I can tell from that discussion, the general opposition to
>> encoding the branch name as a structural part of the commit object is that,
>> for some people's workflows, it would be unhelpful and/or misleading. Well
>> fair enough then - why don't we make it a setting that is off by default,
>> and can easily be switched on?  That way the people for whom tagging the
>> branch name would be useful have a very easy way to switch it on.
>
> Obviously, the feature would necessarily have to be optional, simply
> because Git would have to keep understanding the old commit object
> format for a LONG time (probably indefinitely), and there's nothing
> you can do to prevent others from creating old-style commit objects.
>
> Which brings us to another big con at this point: The cost of changing
> the commit object format. One can argue for or against a new commit
> object format, but the simple truth at this point is that changing the
> structure of the commit object is expensive. Even if we were all in
> agreement about the change (and so far we are not), there are multiple
> Git implementations (libgit2, jgit, dulwich, etc.) that would all have
> to learn the new commit object, not to mention that bumping
> core.repositoryformatversion would probably make your git repo
> incompatible with a huge number of existing deployments for the
> foreseeable future.
>
> Therefore, the most pragmatic and constructive thing to do at this
> point, is IMHO to work within the confines of the existing commit
> object structure. I actually believe using commit message trailers
> like "Made-on-branch: frotz" in addition to some helpful
> infrastructure (hooks, templates, git-interpret-trailers, etc.) should
> get you pretty much exactly what you want. And if this feature turns
> out to be extremely useful for a lot of users, we can certainly
> consider changing the commit object format in the future.
>
>> I know
>> that for the workflows I personally have used in the past, such tagging
>> would be very useful.  Quite often I have been looking through the Git log
>> and wondered what feature a commit was "part of", because I have feature
>> branches.  Just knowing that branch name would be really useful, but the
>> branch has since been deleted... and in the case of a ff-merge (which I
>> thought was recommended in Git if possible), the branch name is completely
>> gone.
>
> True. The branch name is - for better or worse - simply not considered
> very important by Git, and a Git commit is simply not considered (by
> Git at least) to "be part of" or otherwise "belong to" any branch.
> Instead the commit history/graph is what Git considers important, and
> the branch names are really just more-or-less ephemeral pointers into
> that graph.
>
> AFAIK, recording the current branch name in commits was not considered
> to the worth including in Linus' original design, and since then it
> seems to only have come up a few times on the mailing list. This is
> quite central to Git's design, and changing it at this point should
> not be done lightly.
>
> IINM, Mercurial does this differently, so that may be a better fit for
> the workflows where keeping track of branch names is very important.
>
>>> That said, you are of course free to add this information to your own
>>> commit messages, by appending something like "Made-on-branch: frotz".
>>> In a company setting, you can even create a commit message template or
>>> (prepare-)commit-msg hook to have this line created automatically for
>>> you and your co-workers. You could even append such information
>>> retroactively to existing commits with "git notes". There is also the
>>> current interpret-trailers effort by Christian Couder [1] that should
>>> be useful in creating and managing such lines.
>>>
>>> [1]: http://thread.gmane.org/gmane.comp.version-control.git/245874
>>
>> Well I guess that's another way of doing it.  So, why aren't Author and Date
>> trailers?  They don't seem any more fundamental to me than branch name.  I
>> mean the only checkin information you really *need* is the checksum, and
>> commit's parents.  The Author and Date are just extra pieces of information
>> you might find useful sometimes, right?  A bit like some people might find
>> branch checkin name useful sometimes...?
>
> Yeah, sure. Author and Date (and Committer, for that matter) is just
> metadata, and the current branch name is simply just another kind of
> metadata. All of them are more-or-less free-form text fields, and off

no they're not.  In strictly controlled environments they form part of
the audit record for the source code.

Yes they can be faked (explicitly), but -- again in strictly controlled
environments -- that can be limited to "before it was first pushed".