Recording the current branch on each commit?

classic Classic list List threaded Threaded
73 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Recording the current branch on each commit?

Jeremy Morton-2
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)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: Recording the current branch on each commit?

Robin Rosenberg-2


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

> Från: "Jeremy Morton" <[hidden email]>
> Till: [hidden email]
> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: Recording the current branch on each commit?

Johan Herland
In reply to this post by Jeremy Morton-2
On Sun, Apr 27, 2014 at 1:56 AM, Jeremy Morton <[hidden email]> 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, <[hidden email]>
www.herland.net
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: Recording the current branch on each commit?

Jeremy Morton-2
In reply to this post by Robin Rosenberg-2
On 27/04/2014 09:51, Robin Rosenberg 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.  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)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: Recording the current branch on each commit?

Jeremy Morton-2
In reply to this post by Johan Herland
On 27/04/2014 10:09, Johan Herland wrote:

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

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

>> 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)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: Recording the current branch on each commit?

Johan Herland
On Sun, Apr 27, 2014 at 7:38 PM, Jeremy Morton <[hidden email]> wrote:

> On 27/04/2014 10:09, Johan Herland wrote:
>> On Sun, Apr 27, 2014 at 1:56 AM, Jeremy Morton<[hidden email]>
>> 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
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...

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

[...]

>> 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, <[hidden email]>
www.herland.net
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: Recording the current branch on each commit?

Jeremy Morton-2
On 27/04/2014 20:33, Johan Herland wrote:

> On Sun, Apr 27, 2014 at 7:38 PM, Jeremy Morton<[hidden email]>  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)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: Recording the current branch on each commit?

James Denholm
In reply to this post by Jeremy Morton-2
I'm skipping a lot of the discussion here, sorry about that, but
on one particular note:

Jeremy Morton <[hidden email]> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: Recording the current branch on each commit?

Jeremy Morton-2
On 27/04/2014 22:40, James Denholm wrote:

>> 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)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: Recording the current branch on each commit?

James Denholm
Jeremy Morton <[hidden email]> wrote:

>On 27/04/2014 22:40, James Denholm wrote:
>>> 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.

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.

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: Recording the current branch on each commit?

Johan Herland
In reply to this post by Jeremy Morton-2
On Sun, Apr 27, 2014 at 10:55 PM, Jeremy Morton <[hidden email]> wrote:

> On 27/04/2014 20:33, Johan Herland wrote:
>> On Sun, Apr 27, 2014 at 7:38 PM, Jeremy Morton<[hidden email]>
>> 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 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.

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

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

>>>   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, <[hidden email]>
www.herland.net
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: Recording the current branch on each commit?

Sitaram Chamarty
In reply to this post by Johan Herland
On 04/28/2014 01:03 AM, Johan Herland wrote:

> On Sun, Apr 27, 2014 at 7:38 PM, Jeremy Morton <[hidden email]> wrote:
>> On 27/04/2014 10:09, Johan Herland wrote:
>>> On Sun, Apr 27, 2014 at 1:56 AM, Jeremy Morton<[hidden email]>
>>> 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".
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: Recording the current branch on each commit?

David Kastrup
In reply to this post by Johan Herland
Johan Herland <[hidden email]> writes:

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

Personally, I am _strongly_ opposed.  How I name and juggle my private
branches is nobody else's business in a distributed version control
system.

They are private.  My personal workflow.  Not part of a commit.

--
David Kastrup
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

RE: Recording the current branch on each commit?

Max Kirillov
In reply to this post by Jeremy Morton-2
Hi.

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

Doesn't git ignores unknown headers? I has been investigating this issue
and it looked like it does.

Could the API to add commit headers (which exists in sources) be added
to cli, so users can create the branches, phases or whatever they feel
useful?

--
Max

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

RE: Recording the current branch on each commit?

Max Kirillov
In reply to this post by Jeremy Morton-2
> Personally, I am _strongly_ opposed.  How I name and juggle my private
> branches is nobody else's business in a distributed version control
> system.
>
> They are private.  My personal workflow.  Not part of a commit.

Mercurial inherits the branch label from previous commit, unless
it's specified by user, I think this could be quite reasonable behavior.
(if make them at all, I don't think this specific branch label feature
should be implemented in git core, but rather there should be a way
to extend git so that it makes them)

--
Max
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: Recording the current branch on each commit?

Christian Couder
In reply to this post by Johan Herland
From: Johan Herland <[hidden email]>
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 <[hidden email]> wrote:
>> On 27/04/2014 20:33, Johan Herland wrote:
>>> On Sun, Apr 27, 2014 at 7:38 PM, Jeremy Morton<[hidden email]>
>>> 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 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: Recording the current branch on each commit?

Felipe Contreras
In reply to this post by Jeremy Morton-2
Jeremy Morton wrote:

> On 27/04/2014 09:51, Robin Rosenberg 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.  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.

> > 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: Recording the current branch on each commit?

Jeremy Morton-2
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.

>> 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)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: Recording the current branch on each commit?

Felipe Contreras
In reply to this post by Jeremy Morton-2
Jeremy Morton wrote:

> On 27/04/2014 10:09, Johan Herland wrote:
> > On Sun, Apr 27, 2014 at 1:56 AM, Jeremy Morton<[hidden email]>  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.

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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: Recording the current branch on each commit?

Jeremy Morton-2
In reply to this post by Sitaram Chamarty
On 28/04/2014 03:30, Sitaram Chamarty wrote:

> On 04/28/2014 01:03 AM, Johan Herland wrote:
>> 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)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
1234