Recording the current branch on each commit?

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.  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.  Basically, I'm saying that well-named 
branches can and do carry useful contextual information that oughtn't to 
be thrown away.  Currently, when you delete that branch, you lose the 
branch name altogether.

So what do you think?  Would it be good to have a patch to add this feature?

-- 
Best regards,
Jeremy Morton (Jez)

----- Ursprungligt meddelande -----

Från: "Jeremy Morton" [off-list ref]
Till: git@vger.kernel.org
Skickat: söndag, 27 apr 2014 1:56:47
Ämne: Recording the current branch on each commit?

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.  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.  Basically, I'm saying that well-named
branches can and do carry useful contextual information that oughtn't to
be thrown away.  Currently, when you delete that branch, you lose the
branch name altogether.

So what do you think?  Would it be good to have a patch to add this feature?

Branch names are usually poorly named, so often you don't lose much. One way
some people to is to always merge with --no-ff, that way you see the branch
name in the merge commit. 

A very popular way of tracking context is to add some id, such as a bugzilla issue
number, to the header or footer of the commit message. Often a branch contains many
issues, but the branch itself isn't very interesting. Tools like gitblit, gitweb,
gerrit etc can easily be configured to link to the issue using a regular expression.

-- robin

On Sun, Apr 27, 2014 at 1:56 AM, Jeremy Morton [off-list ref] 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.

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

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
issue in some bug/issue tracker, and it would in any case be natural
to mention the bug/issue ID in the commit message, at which point the
tracker can provide more context and discussion.

Basically,
I'm saying that well-named branches can and do carry useful contextual
information that oughtn't to be thrown away.  Currently, when you delete
that branch, you lose the branch name altogether.

Some would argue that branches are not always well-named... But
anyway, if the branch ends up getting merged to the mainline, the
merge commit defaults to a message like "Merge branch
'pacman-minigame'".

So what do you think?  Would it be good to have a patch to add this feature?

One is free to try, of course, but I wouldn't get my hopes up for a
patch that changes the fundamental format of the commit object to
include something that many users/workflows would consider to be pure
cruft.

If you still believe that this is useful enough to warrant a change to
the commit object format, it is probably better to start off putting
the information in the commit message (as described above), and
provide some tools that demonstrate the added value of this
information. If that is successful and gains momentum, the git
community can certainly reconsider whether it makes sense to fold it
into a more formalized part of the commit object.

...Johan

-- 
Johan Herland, [off-list ref]
www.herland.net

On 27/04/2014 09:51, Robin Rosenberg wrote:

quoted

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.  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.  Basically, I'm saying that well-named
branches can and do carry useful contextual information that oughtn't to
be thrown away.  Currently, when you delete that branch, you lose the
branch name altogether.

So what do you think?  Would it be good to have a patch to add this feature?

Branch names are usually poorly named, so often you don't lose much. One way

Speak for yourself - I give my branches useful names.  :-)  I definitely 
feel that I am often losing useful contextual information by throwing 
away the branch name.

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?  Also, it is a lot more hassle 
(and no doubt, CPU cycles) to track down where a branch was merged to 
try and figure out which branch name a commit pertained to, not to 
mention the fact that the commit could've been moved since.  Nothing 
short of tagging the commit with the branch name when the commit is made 
will definitely record the branch name at the time of committing.

A very popular way of tracking context is to add some id, such as a bugzilla issue
number, to the header or footer of the commit message. Often a branch contains many
issues, but the branch itself isn't very interesting. Tools like gitblit, gitweb,
gerrit etc can easily be configured to link to the issue using a regular expression.

Yes, and I have done this kind of thing in the past.  However you really 
don't want to put the bug# on every single commit pertaining to that 
bug; you have to go to the effort of looking the bug# up every time, 
you'll sometimes forget, and besides it takes up space that could be 
used for a commit message.  As short commit messages are valued in Git, 
it's particularly bad to waste space this way.  Much better would be to 
include the bug# as part of the branch name, and then if you record the 
branch name upon checkin you always get a reference to the bug#.

Also, you don't always have something you can link a commit to in an 
issue tracker.  You may just be implementing a feature that has been 
agreed upon, independently of any such tracker.  In that case, there's 
no bug# to link to.

-- 
Best regards,
Jeremy Morton (Jez)

On 27/04/2014 10:09, Johan Herland wrote:

On Sun, Apr 27, 2014 at 1:56 AM, Jeremy Morton[off-list ref]  wrote:

quoted

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

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

quoted

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.

issue in some bug/issue tracker, and it would in any case be natural
to mention the bug/issue ID in the commit message, at which point the
tracker can provide more context and discussion.

I think it would only be natural to mention the bug# in the final commit 
that actually fixes the bug or implements the feature, not the checkins 
leading up to that.  And, it's still not *guaranteed* that the coder 
will remember to put the bug# in even that commit message.

quoted

Basically,
I'm saying that well-named branches can and do carry useful contextual
information that oughtn't to be thrown away.  Currently, when you delete
that branch, you lose the branch name altogether.

Some would argue that branches are not always well-named... But

But when they are, why should that info be thrown away?  When they're 
not well-named, they can be ignored (or the branch name recording 
feature can be turned off!)

anyway, if the branch ends up getting merged to the mainline, the
merge commit defaults to a message like "Merge branch
'pacman-minigame'".

Only if it's a non-ff merge, which results in less tidy commit trees, 
and hence is often recommended against.  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?

-- 
Best regards,
Jeremy Morton (Jez)

On Sun, Apr 27, 2014 at 7:38 PM, Jeremy Morton [off-list ref] wrote:

On 27/04/2014 10:09, Johan Herland wrote:

quoted

On Sun, Apr 27, 2014 at 1:56 AM, Jeremy Morton[off-list ref]
wrote:

quoted

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.

quoted

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

quoted

quoted

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.

[...]

quoted

anyway, if the branch ends up getting merged to the mainline, the
merge commit defaults to a message like "Merge branch
'pacman-minigame'".

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.

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.

 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.


Hope this helps,

...Johan

-- 
Johan Herland, [off-list ref]
www.herland.net

On 27/04/2014 20:33, Johan Herland wrote:

On Sun, Apr 27, 2014 at 7:38 PM, Jeremy Morton[off-list ref]  wrote:

quoted

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.

quoted

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.

quoted

quoted

quoted

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.

quoted

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.

quoted

  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)

I'm skipping a lot of the discussion here, sorry about that, but
on one particular note:

Jeremy Morton [off-list ref] wrote:

(...) and besides it takes up space that could be 
used for a commit message.  As short commit messages are valued in Git,
it's particularly bad to waste space this way.

Not really. While different groups will have different values, the
"greater git community" seems to prefer short _first lines_,
of fifty chars or less, while the _body_ should be as verbose as
it needs to be (but not more than). Ergo, while the first
line shouldn't contain a swath of metadata, the body can
easily.

A particularly good example of this is almost every commit to
the git project itself - there are"Signed-of-by" lines and such
everywhere in the logs.

Also, you don't always have something you can link a commit to in an 
issue tracker.  You may just be implementing a feature that has been 
agreed upon, independently of any such tracker.  In that case, there's 
no bug# to link to.

In which case, refer to whatever system you use. If you aren't
using a ticketing system, have the line "Relates-to: Water
cooler conversation with Bob on July 28th" or whatever the
patches relate to.

(Arguably, though, the better solution is to use a ticketing
system, or anything that allows discussion to be easily
referenced.)

Regards,
James Denholm.

On 27/04/2014 22:40, James Denholm wrote:

quoted

Also, you don't always have something you can link a commit to in an
issue tracker.  You may just be implementing a feature that has been
agreed upon, independently of any such tracker.  In that case, there's
no bug# to link to.

In which case, refer to whatever system you use. If you aren't
using a ticketing system, have the line "Relates-to: Water
cooler conversation with Bob on July 28th" or whatever the
patches relate to.

(Arguably, though, the better solution is to use a ticketing
system, or anything that allows discussion to be easily
referenced.)

Well, as I said elsewhere in this discussion, Git should provide that 
functionality built-in, IMHO.  It would be good to be able to set a 
one-liner in my .gitconfig to tag each commit with a "branch checked 
into" trailer.

-- 
Best regards,
Jeremy Morton (Jez)

Jeremy Morton [off-list ref] wrote:

On 27/04/2014 22:40, James Denholm wrote:

quoted

quoted

Also, you don't always have something you can link a commit to in an
issue tracker.  You may just be implementing a feature that has been
agreed upon, independently of any such tracker.  In that case,

there's

quoted

quoted

no bug# to link to.

In which case, refer to whatever system you use. If you aren't
using a ticketing system, have the line "Relates-to: Water
cooler conversation with Bob on July 28th" or whatever the
patches relate to.

(Arguably, though, the better solution is to use a ticketing
system, or anything that allows discussion to be easily
referenced.)

Well, as I said elsewhere in this discussion, Git should provide that 
functionality built-in, IMHO.  It would be good to be able to set a 
one-liner in my .gitconfig to tag each commit with a "branch checked 
into" trailer.

In that case, write something onto your post-commit hook and the
functionality would be achieved. A relates-to line doesn't need a
change to the structure of git commits.

On Sun, Apr 27, 2014 at 10:55 PM, Jeremy Morton [off-list ref] wrote:

On 27/04/2014 20:33, Johan Herland wrote:

quoted

On Sun, Apr 27, 2014 at 7:38 PM, Jeremy Morton[off-list ref]
wrote:

quoted

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 think this is what the interpret-trailers effort is about.
Unfortunately I have not followed it closely enough to say if your use
case is already covered by Christian's (CCed) work. Christian: With
your current patch series, is it possible for Jeremy to configure
interpret-trailers to automatically append a "Made-on-branch:
<current_branch>" trailer whenever he creates a commit?

[...]

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.

Which - if you squint at it a little - is sort of what the
interpret-trailers effort does. AFAIK, it (combined with hooks) allows
you to configure a set of optional s/headers/trailers/ and the
policies surrounding those.

quoted

quoted

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?

There are a lot of variables here, and it really comes down to your
(team's) preferred workflow. Different teams/people prefer different
workflows, and git's toolbox allows a wide (probably the widest among
any VCS) variety of workflows to be expressed. So I really cannot make
any sweeping/simple recommendations that will apply to all cases.

Although I prefer collecting related commits on a topic branch that
are then (non-ff) merged into master, I also see the value of
performing a quick single-commit bugfix directly on master. In the
latter case, the commit should obviously be self-sufficient and
self-explanatory. However, once your work start spanning more than a
few commits, you should really think about putting it on a separate
branch, where it can be (re)organized in a way that is logical and
reviewable (interactive rebase FTW).

When I think about it, this might only apply to centralized workflows
where team members (typically co-workers) push their own work to a
shared repository/branch. As a counterexample: in git.git, pretty much
every change (whether it consists of a single patch, or a series of
patches) gets its own "$who/$what" branch in Junio's tree, and are
then merged to 'pu'. When deemed worthy, they are merged to 'next' and
- later - to 'master'. So here, even single-commit changes get their
own branch and subsequent merge commit. Likewise, with GitHub's
pull-request workflow, you make changes on a branch in one repo, and
then request that branch to be pulled (i.e. merged) into another repo,
regardless of whether it consists of one or many commits.

However, one sweeping recommendation that I _can_ make across all
workflows is this: _Think_ about your commit history. Treat it with
the same respect and attention to quality as your code (or whatever
your "main" work product is). A well-organized history with good
commit messages is an invaluable tool in grokking how the current
state of a project has come to be, and it encodes a great deal of
knowledge about the project from its developers, and can be of great
help when debugging.

quoted

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.

Agreed, and I believe Junio has also stated that the default behavior
of "git pull" is better suited for maintainers (like Junio and Linus)
that pull from downstreams, rather than regular
contributors/co-workers that more often pull from their upstream. "git
pull --rebase" (or branch.<name>.rebase, or even
branch.autosetuprebase) is one way to work around that, but even that
can also be abused if you do in indiscriminately (can lead to
different topics being interleaved in-line on master, which makes it
hard to identify which commits belong to which topic). Again, the
ideal is for people to think about what they're doing, and not just
run commands blindly...

quoted

quoted

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

Actually no, "git log M^1..M^2" shows you all commits reachable from
M^2 that are not reachable from M^1, and assuming your merge went
_from_ master and _to_ the branch (NOT the other way), it will show
all the commits to the branch (3 x A + 3 x B). Illustration:

   o---o---o---o---o---o---o---M     <-- master
    \           \             /
     A---A---A---m---B---B---B       <-- branch

The initial commits (3 x A) on the branch before the intermediate
merge from master (m) are not reachable from M^1 (the last 'o' before
M), thus they _will_ show up in "git log M^1..M^2". This holds no
matter how many merges are done from master to branch.

Obviously, if the merge had gone the other way, like this:

   o---o---o---m---o---o---M     <-- master
    \         /           /
     A---A---A---B---B---B       <-- branch

then the initial branch commits (3 x A) preceding 'm', will not be
shown by "git log M^1..M^2", but that is because they have already
entered the master branch (at m). Whether you still consider them part
of the same branch as the 3 x B commits is really a philosophical
question at that point.


...Johan

-- 
Johan Herland, [off-list ref]
www.herland.net

On 04/28/2014 01:03 AM, Johan Herland wrote:

On Sun, Apr 27, 2014 at 7:38 PM, Jeremy Morton [off-list ref] wrote:

quoted

On 27/04/2014 10:09, Johan Herland wrote:

quoted

On Sun, Apr 27, 2014 at 1:56 AM, Jeremy Morton[off-list ref]
wrote:

quoted

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.

quoted

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.

quoted

quoted

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

From: Johan Herland <redacted>
Subject: Re: Recording the current branch on each commit?
Date: Mon, 28 Apr 2014 01:39:26 +0200

On Sun, Apr 27, 2014 at 10:55 PM, Jeremy Morton [off-list ref] wrote:

quoted

On 27/04/2014 20:33, Johan Herland wrote:

quoted

On Sun, Apr 27, 2014 at 7:38 PM, Jeremy Morton[off-list ref]
wrote:

quoted

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 think this is what the interpret-trailers effort is about.
Unfortunately I have not followed it closely enough to say if your use
case is already covered by Christian's (CCed) work. Christian: With
your current patch series, is it possible for Jeremy to configure
interpret-trailers to automatically append a "Made-on-branch:
<current_branch>" trailer whenever he creates a commit?

Yes, it's possible. Yesterday, I sent the following patch:

[RFC/PATCH 2/2] trailer: add examples to the documentation

and it shows a commit-msg hook to do something like that:

$ cat >.git/hooks/commit-msg <<EOF
#!/bin/sh
git interpret-trailers --trim-empty --trailer "git-version: \$(git describe)" "\$1" > "\$1.new"
mv "\$1.new" "\$1"
EOF
$ chmod +x .git/hooks/commit-msg

I think you just need to use the following if you want the branch
instead of the git version:

git interpret-trailers --trim-empty --trailer "git-branch: \$(git name-rev --name-only HEAD)" "\$1" > "\$1.new"

It could even be simpler if there was an option (which has already
been discussed) that made it possible to modify the file in
place. This way one would not need the 'mv "\$1.new" "\$1"' command.

Best,
Christian.

Jeremy Morton wrote:

On 27/04/2014 09:51, Robin Rosenberg wrote:

quoted

quoted

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.  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.  Basically, I'm saying that well-named
branches can and do carry useful contextual information that oughtn't to
be thrown away.  Currently, when you delete that branch, you lose the
branch name altogether.

So what do you think?  Would it be good to have a patch to add this feature?

Branch names are usually poorly named, so often you don't lose much. One way

Speak for yourself - I give my branches useful names.  :-)

Me too.

I definitely feel that I am often losing useful contextual information by
throwing away the branch name.

I don't.

quoted

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.

Also, it is a lot more hassle (and no doubt, CPU cycles) to track down where
a branch was merged to try and figure out which branch name a commit
pertained to, not to mention the fact that the commit could've been moved
since.  Nothing short of tagging the commit with the branch name when the
commit is made will definitely record the branch name at the time of
committing.

But why do you need that information?

-- 
Felipe Contreras

On 28/04/2014 09:32, Felipe Contreras wrote:

quoted

quoted

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.

quoted

Also, it is a lot more hassle (and no doubt, CPU cycles) to track down where
a branch was merged to try and figure out which branch name a commit
pertained to, not to mention the fact that the commit could've been moved
since.  Nothing short of tagging the commit with the branch name when the
commit is made will definitely record the branch name at the time of
committing.

But why do you need that information?

As I said before, I usually consider my branch names useful information 
worth keeping around - I'm not sure why you don't.  I might include a 
bug# in the branch name so I don't have to keep typing it in every 
commit message, or I might just have a handy short description of what 
part of the application this branch is modifying (like my 
"pacman-minigame" example).

-- 
Best regards,
Jeremy Morton (Jez)

On 28/04/2014 03:30, Sitaram Chamarty wrote:

On 04/28/2014 01:03 AM, Johan Herland wrote:

quoted

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

Why these specific headers as part of the audit record, though?  Aren't 
you just arbitrarily defining them as part of the audit record?

-- 
Best regards,
Jeremy Morton (Jez)

Jeremy Morton wrote:

On 27/04/2014 10:09, Johan Herland wrote:

quoted

On Sun, Apr 27, 2014 at 1:56 AM, Jeremy Morton[off-list ref]  wrote:

quoted

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.

s/some people's workflows/most workflows/

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

I still don't see why you would need that information, but if you really need
it, you can write a commit hook that stores that information in the message,
it's very trivial. Also, you can store that information in notes.

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?

By recording the start of the branch.

[1] https://github.com/felipec/git/commits/fc/tail

-- 
Felipe Contreras

On 28/04/2014 07:45, Christian Couder wrote:

Yes, it's possible. Yesterday, I sent the following patch:

[RFC/PATCH 2/2] trailer: add examples to the documentation

and it shows a commit-msg hook to do something like that:

$ cat>.git/hooks/commit-msg<<EOF
#!/bin/sh
git interpret-trailers --trim-empty --trailer "git-version: \$(git describe)" "\$1">  "\$1.new"
mv "\$1.new" "\$1"
EOF
$ chmod +x .git/hooks/commit-msg

I think you just need to use the following if you want the branch
instead of the git version:

git interpret-trailers --trim-empty --trailer "git-branch: \$(git name-rev --name-only HEAD)" "\$1">  "\$1.new"

It could even be simpler if there was an option (which has already
been discussed) that made it possible to modify the file in
place. This way one would not need the 'mv "\$1.new" "\$1"' command.

Best,
Christian.

This is certainly going in the right direction, but it's still 
implemented as a hook on a per-repo basis.  Do you foresee a point in 
the future where these trailers could be added through simple one-liners 
in someone's global .gitconfig file?  That's where I'd really like to 
get to.

-- 
Best regards,
Jeremy Morton (Jez)

Johan Herland wrote:

On Sun, Apr 27, 2014 at 7:38 PM, Jeremy Morton [off-list ref] wrote:

quoted

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.

It's not that easy. There has been a lot of discussion in the mailing list and
StackOverflow of ways to do this [1]. The conclusion, at least for me, is that
there's no way to find that out, so it has to be recorded.

[1] http://thread.gmane.org/gmane.comp.version-control.git/198587

-- 
Felipe Contreras

On Mon, Apr 28, 2014 at 11:01 AM, Jeremy Morton [off-list ref] wrote:

On 28/04/2014 07:45, Christian Couder wrote:

quoted

Yes, it's possible. Yesterday, I sent the following patch:

[RFC/PATCH 2/2] trailer: add examples to the documentation

and it shows a commit-msg hook to do something like that:

$ cat>.git/hooks/commit-msg<<EOF
#!/bin/sh
git interpret-trailers --trim-empty --trailer "git-version: \$(git
describe)" "\$1">  "\$1.new"
mv "\$1.new" "\$1"
EOF
$ chmod +x .git/hooks/commit-msg

I think you just need to use the following if you want the branch
instead of the git version:

git interpret-trailers --trim-empty --trailer "git-branch: \$(git name-rev
--name-only HEAD)" "\$1">  "\$1.new"

It could even be simpler if there was an option (which has already
been discussed) that made it possible to modify the file in
place. This way one would not need the 'mv "\$1.new" "\$1"' command.

This is certainly going in the right direction, but it's still implemented
as a hook on a per-repo basis.  Do you foresee a point in the future where
these trailers could be added through simple one-liners in someone's global
.gitconfig file?  That's where I'd really like to get to.

It's a hack, but it works surprisingly well in practice (assuming that
you and your co-workers all agree that this is an acceptable
approach):

 1. Write the hook script and add it to your project (in a git-hooks
subdir or something)

 2. Add a post-checkout hook to install the first hook and the
post-checkout hook itself into the user's .git/hooks/ dir.

 3. Tell your co-workers to run the post-checkout hook script manually
the first time. After that, the script should take care of updating
itself and any hooks that you add to the project.


...Johan

-- 
Johan Herland, [off-list ref]
www.herland.net

Jeremy Morton wrote:

On 27/04/2014 20:33, Johan Herland wrote:

quoted

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.

It's not idea. Virtually everyone agrees with that, even Linus Torvalds, and we
have the patches to fix it, but it's not going to change.

The Git project doesn't welcome change.

-- 
Felipe Contreras

On 28/04/2014 10:09, Johan Herland wrote:

On Mon, Apr 28, 2014 at 11:01 AM, Jeremy Morton[off-list ref]  wrote:

quoted

On 28/04/2014 07:45, Christian Couder wrote:

quoted

Yes, it's possible. Yesterday, I sent the following patch:

[RFC/PATCH 2/2] trailer: add examples to the documentation

and it shows a commit-msg hook to do something like that:

$ cat>.git/hooks/commit-msg<<EOF
#!/bin/sh
git interpret-trailers --trim-empty --trailer "git-version: \$(git
describe)" "\$1">   "\$1.new"
mv "\$1.new" "\$1"
EOF
$ chmod +x .git/hooks/commit-msg

I think you just need to use the following if you want the branch
instead of the git version:

git interpret-trailers --trim-empty --trailer "git-branch: \$(git name-rev
--name-only HEAD)" "\$1">   "\$1.new"

It could even be simpler if there was an option (which has already
been discussed) that made it possible to modify the file in
place. This way one would not need the 'mv "\$1.new" "\$1"' command.

This is certainly going in the right direction, but it's still implemented
as a hook on a per-repo basis.  Do you foresee a point in the future where
these trailers could be added through simple one-liners in someone's global
.gitconfig file?  That's where I'd really like to get to.

It's a hack, but it works surprisingly well in practice (assuming that
you and your co-workers all agree that this is an acceptable
approach):

  1. Write the hook script and add it to your project (in a git-hooks
subdir or something)

  2. Add a post-checkout hook to install the first hook and the
post-checkout hook itself into the user's .git/hooks/ dir.

  3. Tell your co-workers to run the post-checkout hook script manually
the first time. After that, the script should take care of updating
itself and any hooks that you add to the project.


...Johan

I don't understand why the co-workers need to run the post-checkout hook 
script manually the first time?

-- 
Best regards,
Jeremy Morton (Jez)

On 28/04/2014 10:01, Felipe Contreras wrote:

Jeremy Morton wrote:

quoted

On 27/04/2014 20:33, Johan Herland wrote:

quoted

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.

It's not idea. Virtually everyone agrees with that, even Linus Torvalds, and we
have the patches to fix it, but it's not going to change.

The Git project doesn't welcome change.

Well, you sure don't seem to.  Why are there so many "no-can-do" people 
on this list?  :-)

-- 
Best regards,
Jeremy Morton (Jez)

Jeremy Morton wrote:

On 28/04/2014 10:01, Felipe Contreras wrote:

quoted

Jeremy Morton wrote:

quoted

On 27/04/2014 20:33, Johan Herland wrote:

quoted

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.

It's not idea. Virtually everyone agrees with that, even Linus Torvalds, and we
have the patches to fix it, but it's not going to change.

The Git project doesn't welcome change.

Well, you sure don't seem to.  Why are there so many "no-can-do" people 
on this list?  :-)

I don't seem to what? I'm the one arguing for change, and I sent the patches to
fix this default behavior.

-- 
Felipe Contreras

On 28/04/2014 10:17, Felipe Contreras wrote:

I don't seem to what? I'm the one arguing for change, and I sent the patches to
fix this default behavior.

Well maybe you should work on phrasing things better - you come across 
as quite negative.

-- 
Best regards,
Jeremy Morton (Jez)

On 04/28/2014 02:22 PM, Jeremy Morton wrote:

On 28/04/2014 03:30, Sitaram Chamarty wrote:

quoted

On 04/28/2014 01:03 AM, Johan Herland wrote:

quoted

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

Why these specific headers as part of the audit record, though?
Aren't you just arbitrarily defining them as part of the audit record?

"who did it" and "when did they do it" are a fair bit more central to
"how did we get here" (viz., the SHA1 of the top commit, if you will)
than "what branch was this commit born in (or similar)".

Here's an example from somewhere I worked (indirectly) in the late 90s.
Nasty bug, easily fixable (a few characters to change).  Customer group
all p-ed off. Developer has access to the version control server.  He
changes something on the VC system to appear as if the bug never existed
in the version of the code he shipped to whoever. As a result, the bug
was deemed to have "mysteriously" appeared somewhere along the line.  It
didn't help that parts of the workflow were semi-manual, so he *did*
have vague things to point at.

I don't believe I can explain that any better or go into details without
some risk, so if you don't agree then that's all there is to it.

Suffice it to say I am strongly opposed to the idea, but as long as it's
optional -- and for the right reasons (see my other email) -- I'd be OK.

Jeremy Morton wrote:

On 28/04/2014 10:17, Felipe Contreras wrote:

quoted

I don't seem to what? I'm the one arguing for change, and I sent the
patches to fix this default behavior.

Well maybe you should work on phrasing things better - you come across as
quite negative.

What is the difference between a negative person and a realist, when what both
say are the same and true?

It's literally almost impossible to change an existing behavior in Git,
including the default behavior of 'git pull`, even if basically everybody
agrees the current behavior is wrong. That's just a fact.

-- 
Felipe Contreras

On Mon, 28 Apr 2014, Jeremy Morton wrote:

On 28/04/2014 10:09, Johan Herland wrote:

quoted

On Mon, Apr 28, 2014 at 11:01 AM, Jeremy Morton[off-list ref] 
wrote:

quoted

On 28/04/2014 07:45, Christian Couder wrote:

quoted

Yes, it's possible. Yesterday, I sent the following patch:

[RFC/PATCH 2/2] trailer: add examples to the documentation

and it shows a commit-msg hook to do something like that:

$ cat>.git/hooks/commit-msg<<EOF
#!/bin/sh
git interpret-trailers --trim-empty --trailer "git-version: \$(git
describe)" "\$1">   "\$1.new"
mv "\$1.new" "\$1"
EOF
$ chmod +x .git/hooks/commit-msg

I think you just need to use the following if you want the branch
instead of the git version:

git interpret-trailers --trim-empty --trailer "git-branch: \$(git 
name-rev
--name-only HEAD)" "\$1">   "\$1.new"

It could even be simpler if there was an option (which has already
been discussed) that made it possible to modify the file in
place. This way one would not need the 'mv "\$1.new" "\$1"' command.

This is certainly going in the right direction, but it's still implemented
as a hook on a per-repo basis.  Do you foresee a point in the future where
these trailers could be added through simple one-liners in someone's 
global
.gitconfig file?  That's where I'd really like to get to.

It's a hack, but it works surprisingly well in practice (assuming that
you and your co-workers all agree that this is an acceptable
approach):

  1. Write the hook script and add it to your project (in a git-hooks
subdir or something)

  2. Add a post-checkout hook to install the first hook and the
post-checkout hook itself into the user's .git/hooks/ dir.

  3. Tell your co-workers to run the post-checkout hook script manually
the first time. After that, the script should take care of updating
itself and any hooks that you add to the project.


...Johan

I don't understand why the co-workers need to run the post-checkout hook 
script manually the first time?

because git does not trust the contents of the repository, so it won't 
auto-execute a hook that's part of the respository.

You can include a hook, and then have someone run it, and after that it will be 
installed locally and run after every pull (and can therefor replace itself), 
but it requires that they run it manually the first time.

David Lang