Re: Recording the current branch on each commit?

From: David Kastrup <dak@gnu.org>
Date: Apr 28, 2014, 09:23 UTC
Message-ID: <87fvkx6c4z.fsf@fencepost.gnu.org>
In-Reply-To: <535E1AF6.8080609@game-point.net>

Jeremy Morton <admin@game-point.net> writes:

Show 24 quoted lines

> On 28/04/2014 10:02, David Kastrup wrote:
>> Jeremy Morton<admin@game-point.net>  writes:
>>
>>> On 28/04/2014 09:32, Felipe Contreras wrote:
>>>>>> some people to is to always merge with --no-ff, that way you see the branch
>>>>>> name in the merge commit.
>>>>>
>>>>> But surely, it's recommended with Git that you try to avoid doing
>>>>> --no-ff merges to avoid commit noise?
>>>>
>>>> Nope. Different people have different needs, there's no recommendation. If
>>>> anything, the recommendation is to do a ff merge, because that's the default.
>>>
>>> That's what I'm saying.  With an ff merge, you don't get the merge
>>> commit message telling you the branch name.
>>
>> And I don't _want_ that branch name to be recorded.  The whole point of
>> a distributed version control system is that it's nobody else's business
>> how I organize my work before submitting it.
>
> Well it would be optional, so obviously you wouldn't be forced to
> share the branch name.  It's not like we're trying to "pry in" to your
> private development.  It's a way of choosing to share what you may
> consider to be useful contextual information about the commit.

But it isn't useful contextual information about the commit because it is tied to a particular repository.

Show 7 quoted lines

>> It is _totally_ useless information in a distributed development
>> model.  Why would or should anybody be concerned what private
>> branches some submitter has developed his patches in?
>
> Why should anybody be concerned about what commit message some
> submitter has typed in for his commit?  They could just read the
> source code to see what has changed, right?

The commit message is an integral part of a commit. The contents of the commit message are not tied to a particular repository. The branch name, however, is.

> Because the commit message is a way for the submitter to try and make
> it easier for the people looking at the commit to understand what the
> commit is doing.

The commit message is written for an audience and is independent of the repository. The branch name isn't.

> In the same way, a meaningful branch name may also make it easier for
> people looking at the commit to understand what it is doing,

It is nobody's business how I name my branches. I can change the commit message using git commit --amend, but what should happen if I rename the branch a commit is on?

And what nightmare should occur when doing git cherry-pick? What _is_ the originating branch of a cherry-pick? What _is_ the originating branch of a merge commit? Or even of a cherry-picked merge commit?

> or what part of the application it is affecting, or what group of
> commits it is a part of.

If I have useful information to offer to the readers of a commit, it belongs in the commit message. Not in some involuntarily created and leaked piece of metadata specific to my workflow and repository that will be awfully hard to change after the fact.

-- 
David Kastrup