Re: Recording the current branch on each commit?

[Jeremy Morton <admin@game-point.net>]

On 27/04/2014 20:33, 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:
>> 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.
>
> 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.

OK, fair enough.  So I guess what I'd like to see, then, is good 
built-in functionality in Git for these commit message trailers, so that 
they are very easy to turn on.  I'd like to be able to tell 
co-developers to add a one-liner to their git config file rather than 
some post-commit script.

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

Please understand that I know this full well.  :-)  I'm saying that the 
'ephemeral' pointers' names are, in themselves, useful - if, like me, 
you give them meaningful names.  What I'm proposing is pretty much an 
automatic tagging (somehow...) of each commit with the current branch 
name (if one is available); information that carries roughly the same 
weight as the commit message.  It could be crap, but equally it could be 
very useful, in some workflows.  I think most of us can agree on that.

> seems to only have come up a few times on the mailing list. This is

But it has come up more than once, which would seem to indicate that I'm 
not the only one with this request. ;-)

> IINM, Mercurial does this differently, so that may be a better fit for

"If I'm Not Mistaken" - I had to look that one up.

> the workflows where keeping track of branch names is very important.

Nah, I had a look at Mercurial and I think I prefer Git - this branch 
name thing is just my one bugbear.  I definitely prefer Git's concept of 
a staging area rather than just committing all changes.  To do that in 
Mercurial you have to use mq and all the different (IMHO unintuative) 
commands that entails, and if you accidentally "mq commit" then you 
screw everything up. :-)  Mercurial also discourages history rewriting 
(ie. cleaning up of messy commits), which Git doesn't.  I prefer Git's 
approach here too.

> 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
> the top of my head, I can't really say that if we were to design Git
> from scratch today, they wouldn't all become optional trailers (or
> headers, or what-have-you).
>
> However, we're not designing Git from scratch, and we have to work
> with what is already there...

Fair point.

>>>> The branch name can provide useful
>>>> contextual information.  For instance, let's say I'm developing a suite
>>>> of
>>>> games.  If the commit message says "Added basic options dialog", it might
>>>> be
>>>> useful to see that the branch name is "pacman-minigame" indicating that
>>>> the
>>>> commit pertains to the options dialog in the Pacman minigame.
>>>
>>> In that partcular case, ISTM that the context ("pacman-minigame")
>>> would actually be better preserved elsewhere. E.g. the commits touch
>>> files in a particular "minigames/pacman" subdir, or you prefix the
>>> context in the commit message ("pacman-minigame: Added basic options
>>> dialog"). Also, such a "topic" branch is often tied to a specific
>>
>> Again, this is a pain because you have to remember to manually tag every
>> commit message with "pacman-minigame", and it takes up precious space in the
>> (already short) commit message.
>
> Yes, which is why I advise you to look at commit message templates,
> hooks, and interpret-trailers to see if you can find a way to automate
> this for you and your co-workers.

What I'd like to see, then, is this trailer functionality built in to 
Git so that a very minimal amount of setup is needed to get everybody 
using it.  We're basically talking about hijacking the commit messages 
and tacking on information that they weren't really intended to hold 
(ie. stuff the developer hasn't manually typed in as a commit message), 
because of the limitation of the Git commit format.  In hindsight, I 
guess it would've been better to have the Git commit format be more 
flexible in terms of what headers it allows, so that new headers could 
easily be added and some headers could be optional.

>> Only if it's a non-ff merge, which results in less tidy commit trees, and
>> hence is often recommended against.
>
> Not at all. If you're developing a series of commits with a common
> purpose (a.k.a. a topic branch) I would very much argue for
> non-ff-merging this, _exactly_ because the merge commit allows you to
> introduce the entire topic as a single entity. The merge commit
> message (in addition to containing the branch name) is also the
> natural place to describe more general things about the topic as a
> whole - sort of like the cover letter to a patch series.

Would you recommend that every single commit be made in a branch that 
gets merged into master, then?  So, no direct commits to master?

> The problem is not really "less tidy commit trees" - by which I gather
> you mean history graphs that are non-linear. IMHO, the history graph
> should reflect parallel/branched development when that is useful.
> Blindly rebasing everything into a single line is IMHO just as bad as
> doing all your work directly on master and blindly running "git pull"
> between each of your own commits (which results in a lot of useless
> merges). The merge commits themselves are not the problem. Merge
> commits are a tool, and when used properly (to introduce topics to the
> master branch like described above) they are a good tool. When abused
> (like blindly running "git pull" and accepting useless "merge
> bubbles") they create more problems than they solve.

Sounds like the default behaviour of "git pull" might not be ideal if it 
easily causes these problems.

>>   Whatsmore, tracking down which branch a
>> commit pertains to is still rather difficult using this approach.  You can
>> go back through the history and find "Merge branch 'pacman-minigame'", but
>> how do you know which commit was the *start* of that branch, if they are not
>> tagged with the branch name?
>
> Once you have found the merge commit (M), git log M^1..M^2 should list
> all the commits that were made on that branch. The parent of the last
> in that list can be considered the starting point for the branch.

I don't quite understand this; your suggestion would only work on the 
assumption that no merges have been made from master to that branch; git 
log M^1..M^2 will get the most recent common ancestor of the two and 
show the commits between them, but if there has been a merge from master 
to branch, it will not show the commits to the branch before that 
merge... so it's not as useful as tagging.  You'd have to do some work 
to get all the branch's commits, which is rather undesirable when you 
could just see the branch name (when perusing 'git log') if it were 
tagged as part of the commit.

> Hope this helps,
>
> ...Johan

-- 
Best regards,
Jeremy Morton (Jez)