Recording the current branch on each commit?

Recording the current branch on each commit?

[Jeremy Morton]

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)

Re: Recording the current branch on each commit?

[Robin Rosenberg]

----- Ursprungligt meddelande -----
> Från: "Jeremy Morton" <admin@game-point.net>
> 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

Re: Recording the current branch on each commit?

[Jeremy Morton]

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)

Re: Recording the current branch on each commit?

[James Denholm]

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

Jeremy Morton <admin@game-point.net> 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.

Re: Recording the current branch on each commit?

[Jeremy Morton]

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)

Re: Recording the current branch on each commit?

[James Denholm]

Jeremy Morton <admin@game-point.net> 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.

Re: Recording the current branch on each commit?

[Felipe Contreras]

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

Re: Recording the current branch on each commit?

[Jeremy Morton]

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)

Re: Recording the current branch on each commit?

[David Kastrup]

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

> On 28/04/2014 09:32, Felipe Contreras wrote:
>>>> some people to is to always merge with --no-ff, that way you see the branch
>>>> name in the merge commit.
>>>
>>> But surely, it's recommended with Git that you try to avoid doing
>>> --no-ff merges to avoid commit noise?
>>
>> Nope. Different people have different needs, there's no recommendation. If
>> anything, the recommendation is to do a ff merge, because that's the default.
>
> That's what I'm saying.  With an ff merge, you don't get the merge
> commit message telling you the branch name.

And I don't _want_ that branch name to be recorded.  The whole point of
a distributed version control system is that it's nobody else's business
how I organize my work before submitting it.

I don't want to have people tell me when submitting patches "but can't
you give this a better branch name?" and then have to use git
filter-branch or whatever else to get the branch name removed.

> As I said before, I usually consider my branch names useful
> information worth keeping around - I'm not sure why you don't.

It is _totally_ useless information in a distributed development model.
Why would or should anybody be concerned what private branches some
submitter has developed his patches in?

This is not a useful part of a commit.

-- 
David Kastrup

Re: Recording the current branch on each commit?

[Jeremy Morton]

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

Well it would be optional, so obviously you wouldn't be forced to share 
the branch name.  It's not like we're trying to "pry in" to your private 
development.  It's a way of choosing to share what you may consider to 
be useful contextual information about the commit.

> I don't want to have people tell me when submitting patches "but can't
> you give this a better branch name?" and then have to use git
> filter-branch or whatever else to get the branch name removed.
>
>> As I said before, I usually consider my branch names useful
>> information worth keeping around - I'm not sure why you don't.
>
> It is _totally_ useless information in a distributed development model.
> Why would or should anybody be concerned what private branches some
> submitter has developed his patches in?

Why should anybody be concerned about what commit message some submitter 
has typed in for his commit?  They could just read the source code to 
see what has changed, right?

Because the commit message is a way for the submitter to try and make it 
easier for the people looking at the commit to understand what the 
commit is doing.  In the same way, a meaningful branch name may also 
make it easier for people looking at the commit to understand what it is 
doing, or what part of the application it is affecting, or what group of 
commits it is a part of.

-- 
Best regards,
Jeremy Morton (Jez)

Re: Recording the current branch on each commit?

[David Kastrup]

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

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

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

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

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

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

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

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

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

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

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

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

-- 
David Kastrup

Re: Recording the current branch on each commit?

[David Lang]

On Mon, 28 Apr 2014, David Kastrup wrote:

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

It sounds like what you want is really a template for a commit message that lets 
you include arbitrary information in that template, including things like branch 
name that may not make sense for other people.

If there is no commit message, populate the template and show that to the user 
in their editor.

If there is a commit message, don't touch it.

Then people can use whatever they want (including environment variables) as part 
of their messages.

David Lang

Re: Recording the current branch on each commit?

[Junio C Hamano]

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

> But surely, it's recommended with Git that you try to avoid doing
> --no-ff merges to avoid commit noise?

That is a misconception, I am afraid, coming from two different
camps.

Some projects do not want any merges for whatever reason, not
limited to --no-ff merges.  They want linear history perhaps due to
inertia from their CVS days.

In mergy projects, where no such "merge avesion" exists, there still
is a valid reason why you are told to avoid no-ff, but I do not
think it is primarily because no-ff is bad.  The real reason why
people need no-ff to record the fact that the "side branch" was a
separate development is because they rebase on top of the project's
tip right before they push it out.  If you do not do that last
minute rebase, you do not have to do a no-ff, unless the project is
so quiet and no other people are actively working on the codebase.
And in such a case, no-ff would be very much justified.

I do not fundamentally oppose if you want to add "Done-as-part-of:
frotz-topic" at the end of the log message of each commit that
belongs to the topic in your project (I personally wouldn't welcome
such a convention in _this_ project, though).  Christian's
"trailers" series may serve as a building block for such a feature.

But as we can see in the thread, many people view (including me)
that the choice of branch name is a personal thing, irrelevant in
the project-wide history, so even if you add a built-in support to
make it easier for you to add such a trailer, it has to be something
optional the projects explicitly must choose to use by flipping some
toggle.

Re: Recording the current branch on each commit?

[Johan Herland]

On Sun, Apr 27, 2014 at 1:56 AM, Jeremy Morton <admin@game-point.net> wrote:
> Currently, git records a checksum, author, commit date/time, and commit
> message with every commit (as get be seen from 'git log').  I think it would
> be useful if, along with the Author and Date, git recorded the name of the
> current branch on each commit.

This has been discussed multiple times in the past. One example here:
http://thread.gmane.org/gmane.comp.version-control.git/229422

I believe the current conclusion (if any) is that encoding such
information as a _structural_ part of the commit object is not useful.
See the old thread(s) for the actual pro/con arguments.

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, <johan@herland.net>
www.herland.net

Re: Recording the current branch on each commit?

[Jeremy Morton]

On 27/04/2014 10:09, Johan Herland wrote:
> On Sun, Apr 27, 2014 at 1:56 AM, Jeremy Morton<admin@game-point.net>  wrote:
>> Currently, git records a checksum, author, commit date/time, and commit
>> message with every commit (as get be seen from 'git log').  I think it would
>> be useful if, along with the Author and Date, git recorded the name of the
>> current branch on each commit.
>
> This has been discussed multiple times in the past. One example here:
> http://thread.gmane.org/gmane.comp.version-control.git/229422
>
> I believe the current conclusion (if any) is that encoding such
> information as a _structural_ part of the commit object is not useful.
> See the old thread(s) for the actual pro/con arguments.

As far as I can tell from that discussion, the general opposition to 
encoding the branch name as a structural part of the commit object is 
that, for some people's workflows, it would be unhelpful and/or 
misleading.  Well fair enough then - why don't we make it a setting that 
is off by default, and can easily be switched on?  That way the people 
for whom tagging the branch name would be useful have a very easy way to 
switch it on.  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)

Re: Recording the current branch on each commit?

[Johan Herland]

On Sun, Apr 27, 2014 at 7:38 PM, Jeremy Morton <admin@game-point.net> wrote:
> On 27/04/2014 10:09, Johan Herland wrote:
>> On Sun, Apr 27, 2014 at 1:56 AM, Jeremy Morton<admin@game-point.net>
>> wrote:
>>> Currently, git records a checksum, author, commit date/time, and commit
>>> message with every commit (as get be seen from 'git log').  I think it
>>> would
>>> be useful if, along with the Author and Date, git recorded the name of
>>> the
>>> current branch on each commit.
>>
>> This has been discussed multiple times in the past. One example here:
>> http://thread.gmane.org/gmane.comp.version-control.git/229422
>>
>> I believe the current conclusion (if any) is that encoding such
>> information as a _structural_ part of the commit object is not useful.
>> See the old thread(s) for the actual pro/con arguments.
>
> As far as I can tell from that discussion, the general opposition to
> encoding the branch name as a structural part of the commit object is that,
> for some people's workflows, it would be unhelpful and/or misleading. Well
> fair enough then - why don't we make it a setting that is off by default,
> and can easily be switched on?  That way the people for whom tagging the
> branch name would be useful have a very easy way to switch it on.

Obviously, the feature would necessarily have to be optional, simply
because Git would have to keep understanding the old commit object
format for a LONG time (probably indefinitely), and there's nothing
you can do to prevent others from creating old-style commit objects.

Which brings us to another big con at this point: The cost of changing
the commit object format. One can argue for or against a new commit
object format, but the simple truth at this point is that changing the
structure of the commit object is expensive. Even if we were all in
agreement about the change (and so far we are not), there are multiple
Git implementations (libgit2, jgit, dulwich, etc.) that would all have
to learn the new commit object, not to mention that bumping
core.repositoryformatversion would probably make your git repo
incompatible with a huge number of existing deployments for the
foreseeable future.

Therefore, the most pragmatic and constructive thing to do at this
point, is IMHO to work within the confines of the existing commit
object structure. I actually believe using commit message trailers
like "Made-on-branch: frotz" in addition to some helpful
infrastructure (hooks, templates, git-interpret-trailers, etc.) should
get you pretty much exactly what you want. And if this feature turns
out to be extremely useful for a lot of users, we can certainly
consider changing the commit object format in the future.

> I know
> that for the workflows I personally have used in the past, such tagging
> would be very useful.  Quite often I have been looking through the Git log
> and wondered what feature a commit was "part of", because I have feature
> branches.  Just knowing that branch name would be really useful, but the
> branch has since been deleted... and in the case of a ff-merge (which I
> thought was recommended in Git if possible), the branch name is completely
> gone.

True. The branch name is - for better or worse - simply not considered
very important by Git, and a Git commit is simply not considered (by
Git at least) to "be part of" or otherwise "belong to" any branch.
Instead the commit history/graph is what Git considers important, and
the branch names are really just more-or-less ephemeral pointers into
that graph.

AFAIK, recording the current branch name in commits was not considered
to the worth including in Linus' original design, and since then it
seems to only have come up a few times on the mailing list. This is
quite central to Git's design, and changing it at this point should
not be done lightly.

IINM, Mercurial does this differently, so that may be a better fit for
the workflows where keeping track of branch names is very important.

>> That said, you are of course free to add this information to your own
>> commit messages, by appending something like "Made-on-branch: frotz".
>> In a company setting, you can even create a commit message template or
>> (prepare-)commit-msg hook to have this line created automatically for
>> you and your co-workers. You could even append such information
>> retroactively to existing commits with "git notes". There is also the
>> current interpret-trailers effort by Christian Couder [1] that should
>> be useful in creating and managing such lines.
>>
>> [1]: http://thread.gmane.org/gmane.comp.version-control.git/245874
>
> Well I guess that's another way of doing it.  So, why aren't Author and Date
> trailers?  They don't seem any more fundamental to me than branch name.  I
> mean the only checkin information you really *need* is the checksum, and
> commit's parents.  The Author and Date are just extra pieces of information
> you might find useful sometimes, right?  A bit like some people might find
> branch checkin name useful sometimes...?

Yeah, sure. Author and Date (and Committer, for that matter) is just
metadata, and the current branch name is simply just another kind of
metadata. All of them are more-or-less free-form text fields, and off
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, <johan@herland.net>
www.herland.net

Re: Recording the current branch on each commit?

[Jeremy Morton]

On 27/04/2014 20:33, Johan Herland wrote:
> On Sun, Apr 27, 2014 at 7:38 PM, Jeremy Morton<admin@game-point.net>  wrote:
>> On 27/04/2014 10:09, Johan Herland wrote:
>> As far as I can tell from that discussion, the general opposition to
>> encoding the branch name as a structural part of the commit object is that,
>> for some people's workflows, it would be unhelpful and/or misleading. Well
>> fair enough then - why don't we make it a setting that is off by default,
>> and can easily be switched on?  That way the people for whom tagging the
>> branch name would be useful have a very easy way to switch it on.
>
> Therefore, the most pragmatic and constructive thing to do at this
> point, is IMHO to work within the confines of the existing commit
> object structure. I actually believe using commit message trailers
> like "Made-on-branch: frotz" in addition to some helpful
> infrastructure (hooks, templates, git-interpret-trailers, etc.) should
> get you pretty much exactly what you want. And if this feature turns
> out to be extremely useful for a lot of users, we can certainly
> consider changing the commit object format in the future.

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

>> I know
>> that for the workflows I personally have used in the past, such tagging
>> would be very useful.  Quite often I have been looking through the Git log
>> and wondered what feature a commit was "part of", because I have feature
>> branches.  Just knowing that branch name would be really useful, but the
>> branch has since been deleted... and in the case of a ff-merge (which I
>> thought was recommended in Git if possible), the branch name is completely
>> gone.
>
> True. The branch name is - for better or worse - simply not considered
> very important by Git, and a Git commit is simply not considered (by
> Git at least) to "be part of" or otherwise "belong to" any branch.

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

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

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

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

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

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

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

> Yeah, sure. Author and Date (and Committer, for that matter) is just
> metadata, and the current branch name is simply just another kind of
> metadata. All of them are more-or-less free-form text fields, and off
> the top of my head, I can't really say that if we were to design Git
> from scratch today, they wouldn't all become optional trailers (or
> headers, or what-have-you).
>
> However, we're not designing Git from scratch, and we have to work
> with what is already there...

Fair point.

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

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

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

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

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

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

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

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

> Hope this helps,
>
> ...Johan

-- 
Best regards,
Jeremy Morton (Jez)

Re: Recording the current branch on each commit?

[Johan Herland]

On Sun, Apr 27, 2014 at 10:55 PM, Jeremy Morton <admin@game-point.net> wrote:
> On 27/04/2014 20:33, Johan Herland wrote:
>> On Sun, Apr 27, 2014 at 7:38 PM, Jeremy Morton<admin@game-point.net>
>> wrote:
>>> On 27/04/2014 10:09, Johan Herland wrote:
>>> As far as I can tell from that discussion, the general opposition to
>>> encoding the branch name as a structural part of the commit object is
>>> that,
>>> for some people's workflows, it would be unhelpful and/or misleading.
>>> Well
>>> fair enough then - why don't we make it a setting that is off by default,
>>> and can easily be switched on?  That way the people for whom tagging the
>>> branch name would be useful have a very easy way to switch it on.
>>
>> Therefore, the most pragmatic and constructive thing to do at this
>> point, is IMHO to work within the confines of the existing commit
>> object structure. I actually believe using commit message trailers
>> like "Made-on-branch: frotz" in addition to some helpful
>> infrastructure (hooks, templates, git-interpret-trailers, etc.) should
>> get you pretty much exactly what you want. And if this feature turns
>> out to be extremely useful for a lot of users, we can certainly
>> consider changing the commit object format in the future.
>
> OK, fair enough.  So I guess what I'd like to see, then, is good built-in
> functionality in Git for these commit message trailers, so that they are
> very easy to turn on.  I'd like to be able to tell co-developers to add a
> one-liner to their git config file rather than some post-commit script.

I 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, <johan@herland.net>
www.herland.net

Re: Recording the current branch on each commit?

[Christian Couder]

From: Johan Herland <johan@herland.net>
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 <admin@game-point.net> wrote:
>> On 27/04/2014 20:33, Johan Herland wrote:
>>> On Sun, Apr 27, 2014 at 7:38 PM, Jeremy Morton<admin@game-point.net>
>>> wrote:
>>>> On 27/04/2014 10:09, Johan Herland wrote:
>>>> As far as I can tell from that discussion, the general opposition to
>>>> encoding the branch name as a structural part of the commit object is
>>>> that,
>>>> for some people's workflows, it would be unhelpful and/or misleading.
>>>> Well
>>>> fair enough then - why don't we make it a setting that is off by default,
>>>> and can easily be switched on?  That way the people for whom tagging the
>>>> branch name would be useful have a very easy way to switch it on.
>>>
>>> Therefore, the most pragmatic and constructive thing to do at this
>>> point, is IMHO to work within the confines of the existing commit
>>> object structure. I actually believe using commit message trailers
>>> like "Made-on-branch: frotz" in addition to some helpful
>>> infrastructure (hooks, templates, git-interpret-trailers, etc.) should
>>> get you pretty much exactly what you want. And if this feature turns
>>> out to be extremely useful for a lot of users, we can certainly
>>> consider changing the commit object format in the future.
>>
>> OK, fair enough.  So I guess what I'd like to see, then, is good built-in
>> functionality in Git for these commit message trailers, so that they are
>> very easy to turn on.  I'd like to be able to tell co-developers to add a
>> one-liner to their git config file rather than some post-commit script.
> 
> I 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.

Re: Recording the current branch on each commit?

[Jeremy Morton]

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)

Re: Recording the current branch on each commit?

[Johan Herland]

On Mon, Apr 28, 2014 at 11:01 AM, Jeremy Morton <admin@game-point.net> wrote:
> 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.
>
> 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, <johan@herland.net>
www.herland.net

Re: Recording the current branch on each commit?

[Jeremy Morton]

On 28/04/2014 10:09, Johan Herland wrote:
> On Mon, Apr 28, 2014 at 11:01 AM, Jeremy Morton<admin@game-point.net>  wrote:
>> 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.
>>
>> 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)

Re: Recording the current branch on each commit?

[David Lang]

On Mon, 28 Apr 2014, Jeremy Morton wrote:

> On 28/04/2014 10:09, Johan Herland wrote:
>> On Mon, Apr 28, 2014 at 11:01 AM, Jeremy Morton<admin@game-point.net> 
>> wrote:
>>> 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.
>>> 
>>> 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

Re: Recording the current branch on each commit?

[Felipe Contreras]

Jeremy Morton wrote:
> On 27/04/2014 20:33, Johan Herland wrote:
> > 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

Re: Recording the current branch on each commit?

[Jeremy Morton]

On 28/04/2014 10:01, Felipe Contreras wrote:
> Jeremy Morton wrote:
>> On 27/04/2014 20:33, Johan Herland wrote:
>>> 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)

Re: Recording the current branch on each commit?

[Felipe Contreras]

Jeremy Morton wrote:
> On 28/04/2014 10:01, Felipe Contreras wrote:
> > Jeremy Morton wrote:
> >> On 27/04/2014 20:33, Johan Herland wrote:
> >>> 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

Re: Recording the current branch on each commit?

[Jeremy Morton]

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)

Re: Recording the current branch on each commit?

[Felipe Contreras]

Jeremy Morton wrote:
> 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.

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

Re: Recording the current branch on each commit?

[David Kastrup]

Felipe Contreras <felipe.contreras@gmail.com> writes:

> Jeremy Morton wrote:
>> 
>> 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.

I can think of a few other things that "the Git project" or actually
pretty much everybody doesn't welcome.

It becomes easier to actually change things when communicating in a less
abrasive and destructive manner.

At any rate, releases involve time plans and testing periods.
Personally I think that the automerging behavior of "git pull" is one of
the most stupid traps Git has available for beginning contributors to
make a royal mess of their contributions.  It's unbelievable that this
has not been defused a decade ago already.

But it hasn't, and such a change is no longer in a useful time frame for
a 2.0 release.  Unless one wants to push back the 2.0 release
considerably for this alone.  But then everybody will have a favorite
pet peeve, some likely more justified, some less, that he wants to get
into 2.0.  I mean, I just sped up git-blame for serious use cases by a
factor of 3 or so at least, and there will be _no_ API changes and
user-visible consequences with that change.

So what?

If the thing has been important enough to get into 2.0, it has been
important enough to push for it _timely_ so that it had a chance at
considerable testing exposure.

That's what has been done with the "git push" changes.  They were put in
timely, with quite a bit of warning about what will change and what
people are supposed to be doing about it.  Again: bad enough that it
took as long as that to fix this insanely reckless default.  The scale
of the git-pull problem is small in comparison as it only messes up a
single local branch instead of a whole set of upstream branches.

-- 
David Kastrup

Re: Recording the current branch on each commit?

[Felipe Contreras]

David Kastrup wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
> 
> > Jeremy Morton wrote:
> >> 
> >> 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.
> 
> I can think of a few other things that "the Git project" or actually
> pretty much everybody doesn't welcome.
> 
> It becomes easier to actually change things when communicating in a less
> abrasive and destructive manner.

That would make sense if I was the only one with the itch. But I wasn't the
only one, so anybody could take the patches and send them in a less abrasive
maner.

In fact I have been contacted a couple of times privately suggesting me to use
a softer tone in order to get my patches applied, in every time I issue a
challenge. You send the patches, and you follow up the discussion in whatever
tone you see fit, if they get in, I'll accept I'm wrong and use softer tone in
the future. The fact of the matter is that the tone doesn't matter, the patches
don't get in because change is not welcome. Period.

> But it hasn't, and such a change is no longer in a useful time frame for
> a 2.0 release.

I sent the last version of the series in Octoboer 2013, there was more than
enough time to merge them, or somebody else with more political traction to
pick and finish whatever changes where needed (none).

> Unless one wants to push back the 2.0 release considerably for this alone.

Why does it need to be pushed back? Have you looked at the patches? If so, what
is the risk that there will be any problem with them?

> I mean, I just sped up git-blame for serious use cases by a factor of 3 or so
> at least, and there will be _no_ API changes and user-visible consequences
> with that change.

I bet this could get into 2.0, but the big patch has to be split into smaller
patches in order for them to be reviewed properly, and maybe merge a few of
them at a time.

> If the thing has been important enough to get into 2.0, it has been
> important enough to push for it _timely_ so that it had a chance at
> considerable testing exposure.

Really? What important changes does 2.0 have? There's literally nothing of
interest to most users, maybe push.default = simple, but that's it.

-- 
Felipe Contreras

Re: Recording the current branch on each commit?

[James Denholm]

Felipe Contreras <felipe.contreras@gmail.com> wrote:
>David Kastrup wrote:
>> It becomes easier to actually change things when communicating in a
>less
>> abrasive and destructive manner.
>
>That would make sense if I was the only one with the itch. But I wasn't
>the
>only one, so anybody could take the patches and send them in a less
>abrasive
>maner.

It's not anybody else's job to take your patches and drizzle them in the
honey of respectable discourse. They're your patches, nobody else is
going to champion them for you.

>The fact of the matter is that the tone doesn't matter, the patches
>don't get in because change is not welcome. Period.

You neglect the possibility that your personal view of what git should
be differs from other people's. One's views and values aren't correct
just on the virtue of that person having them, and you are no different,
Felipe.

Re: Recording the current branch on each commit?

[Felipe Contreras]

James Denholm wrote:
> Felipe Contreras <felipe.contreras@gmail.com> wrote:
> > David Kastrup wrote:
> > > It becomes easier to actually change things when communicating in a less
> > > abrasive and destructive manner.
> >
> > That would make sense if I was the only one with the itch. But I wasn't the
> > only one, so anybody could take the patches and send them in a less
> > abrasive maner.
> 
> It's not anybody else's job to take your patches and drizzle them in the
> honey of respectable discourse.

It's nobody's job to do anything. This a collaborative effort and in a
collaborative effort everbody chimes in to do different things.

It's not Jeff's patches, they are our patches, they are part of the project.
And it's not unusual for multiple people working on a patch series; one person
doing most of the work, another adding tests, another cleaning updocumentation.
It's also no unheard of from a person picking up a patch series somebody else
stopped working on.

If a patch series is event considered to be merged upstream, that means it
doesn't just benefit the person sending it (e.g. me), it benefits all Git
users.

So "my" patches where by the project and for the project.

> > The fact of the matter is that the tone doesn't matter, the patches don't
> > get in because change is not welcome. Period.
> 
> You neglect the possibility that your personal view of what git should
> be differs from other people's.

Except that in this case virtually everyone agreed the default was wrong. I
already said that.

Clarly you didn't read the relevant discussions where everyone, including Linus
Torvalds, agreed. Did you?

-- 
Felipe Contreras

Re: Recording the current branch on each commit?

[Junio C Hamano]

Felipe Contreras <felipe.contreras@gmail.com> writes:

> Except that in this case virtually everyone agreed the default was wrong. I
> already said that.
>
> Clarly you didn't read the relevant discussions where everyone, including Linus
> Torvalds, agreed. Did you?

My recollection is that everybody agreed that the default was
wrong.  I do not think I saw everybody agreed the patch you are
championing is the right solution to solve that problem.

Re: Recording the current branch on each commit?

[Felipe Contreras]

Junio C Hamano wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
> 
> > Except that in this case virtually everyone agreed the default was wrong. I
> > already said that.
> >
> > Clarly you didn't read the relevant discussions where everyone, including Linus
> > Torvalds, agreed. Did you?
> 
> My recollection is that everybody agreed that the default was
> wrong.  I do not think I saw everybody agreed the patch you are
> championing is the right solution to solve that problem.

I'm going to add the quote you removed:

> > James Denholm wrote:
> > > You neglect the possibility that your personal view of what git should be
> > > differs from other people's.

In this context James was talking about what Git should be. But the vast
majority agree on this issue, so that's not what's preventing change.

-- 
Felipe Contreras

Re: Recording the current branch on each commit?

[Junio C Hamano]

Felipe Contreras <felipe.contreras@gmail.com> writes:

> In this context James was talking about what Git should be. But the vast
> majority agree on this issue, so that's not what's preventing change.

Sorry, I saw "take your patches" from James and "my patch" from you
in the context above that part, and somehow thought that the
discussion was about the reason why a particular implementation that
hit 'pu' once stalled and did not result in changing Git.

I agree that recognition of the issue is not what prevents a change.

Re: Recording the current branch on each commit?

[Felipe Contreras]

Junio C Hamano wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
> 
> > In this context James was talking about what Git should be. But the vast
> > majority agree on this issue, so that's not what's preventing change.
> 
> I agree that recognition of the issue is not what prevents a change.

It's not just recognition of the issue, the solution is agreed too: change the
default. The specifics of exactly how might not be.

-- 
Felipe Contreras

Re: Recording the current branch on each commit?

[James Denholm]

Felipe Contreras <felipe.contreras@gmail.com> wrote:
> James Denholm wrote:
>> It's not anybody else's job to take your patches and drizzle them in the
>> honey of respectable discourse.
>
> It's nobody's job to do anything. This a collaborative effort and in a
> collaborative effort everbody chimes in to do different things.

No, true, but my point was more related to that it's ones own "task",
perhaps being the better term than job, to debate the merits of one's
own work when the merits are currently unknown to the rest of a
community.

> It's not Jeff's patches, they are our patches, they are part of the project.
> And it's not unusual for multiple people working on a patch series; oneperson
> doing most of the work, another adding tests, another cleaning updocumentation.
> It's also no unheard of from a person picking up a patch series somebody else
> stopped working on.

This, of course, would be the _other_ case where a proposal's
merits are already known and accepted by the community. Different
situation.

Note that I here specify a proposal's merits are known and accepted,
rather than the issue at hand. I'd be very, very surprised if there was
even a few cases in human history where a community was able to
collaboratively work, efficiently and successfully, on a proposal where
the merits were still hotly discussed (barring, of course, exploratory
works).

> If a patch series is event considered to be merged upstream, that means it
> doesn't just benefit the person sending it (e.g. me), it benefits all Git
> users.
>
> So "my" patches where by the project and for the project.

And yes, of course, but you misinterpret my use of "one's patches" to
describe ownership or who benefits from those patches. I merely
discuss authorship and seek not to imply anything more.

>> > The fact of the matter is that the tone doesn't matter, the patches don't
>> > get in because change is not welcome. Period.
>>
>> You neglect the possibility that your personal view of what git should
>> be differs from other people's.
>
> Except that in this case virtually everyone agreed the default was wrong. I
> already said that.
>
> Clarly you didn't read the relevant discussions where everyone, including Linus
> Torvalds, agreed. Did you?

I'm talking about the general case, not a _specific_ patch or set
thereof authored by you or any one person.

Again, though, recall that even if a community has agreed that
the current state is non-ideal, that doesn't mean that they agree
that a _specific proposal_ is the right one. If A and B agree that
they are starving to death, and B proposes they engage in hunting
to resolve this, A might disagree because he'd rather just go
across the street and buy a loaf of bread.

Although as I write this it seems Junio has described this exact
thing in a following mail, and on the following debate:

A patch relates to more than a personal view of what a project
shouldn't be. Even if it's solving an acknowledged problem, it
by it's nature relates to a view of what the solution should be.

Ergo, in the specific case, your view of what the solution should
have been did not match the community's view of the same, even
if the overall problem was acknowledged by the entire community.

The default may be wrong, you and I might agree that the default is
wrong, Junio and Torvalds and RMS and The Queen of England
might all agree that the default is wrong... But if we all live across
from a bread shop, it's going to be a difficult task for you to convince
us to go hunting.

Sincerely and analogically yours,
James Denholm.

Re: Recording the current branch on each commit?

[Felipe Contreras]

James Denholm wrote:
> Felipe Contreras <felipe.contreras@gmail.com> wrote:
> > James Denholm wrote:
> >> It's not anybody else's job to take your patches and drizzle them in the
> >> honey of respectable discourse.
> >
> > It's nobody's job to do anything. This a collaborative effort and in a
> > collaborative effort everbody chimes in to do different things.
> 
> No, true, but my point was more related to that it's ones own "task",

It's still the same thing. Nobody gets assigned any tasks; people choose their
own tasks, and they might choose tasks that other people were doing.

> > It's not Jeff's patches, they are our patches, they are part of the project.
> > And it's not unusual for multiple people working on a patch series; oneperson
> > doing most of the work, another adding tests, another cleaning updocumentation.
> > It's also no unheard of from a person picking up a patch series somebody else
> > stopped working on.
> 
> This, of course, would be the _other_ case where a proposal's
> merits are already known and accepted by the community.

No. John might have sent a patch series X, and maybe he didn't explain
correctly how it would benefit the project. Later on Mark finds out how those
patches would be useful for himself and takes upon himself to get them merged,
so he cleans them up and send an updated version with a clear explanation of
how they would be useful.

It's still the same proposal X, but a different person and a different strategy
to get them merged.

In other words, the fact that the community has not yet accepted the merits of
an approach doesn't mean that another person cannot champion it.

> The default may be wrong, you and I might agree that the default is
> wrong, Junio and Torvalds and RMS and The Queen of England
> might all agree that the default is wrong... But if we all live across
> from a bread shop, it's going to be a difficult task for you to convince
> us to go hunting.

It doesn't matter if you want to go hunting and I want to buy bread, either one
of those is better than starving to death.

In the Git project though, we choose to starve to death. Neither were my
patches picked, nor did anybody else step up with a different proposal, we just
did nothing, which is what we always do.

-- 
Felipe Contreras

Re: Recording the current branch on each commit?

[James Denholm]

On 29 April 2014 13:32:29 GMT+10:00, Felipe Contreras <felipe.contreras@gmail.com> wrote:
>James Denholm wrote:
>> No, true, but my point was more related to that it's ones own "task",
>> perhaps being the better term than job, to debate the merits of one's
>>own work when the merits are currently unknown to the rest of a
>>community.
>
>It's still the same thing. Nobody gets assigned any tasks; people
>choose their
>own tasks, and they might choose tasks that other people were doing.

Right. Instead of bashing about in the haberdashery of
misinterpretation, allow me to explicitly restate my original
point.

You cannot expect that anybody but yourself is willing to propose,
debate the merits of and otherwise defend patches that you
have authored (herein "your patches", implying 
authorship, not ownership).

Some people *may*, but if they do not or do not successfully,
that does not imply the stagnation of the project.

Ultimately, the only person who can ensure that a patch is
championed, and the only person who need feel a
responsibility to, is the author, and that responsibility
is only ever to themselves.

TL,DR: Champion your own patches, don't ask others to.

>> > It's not Jeff's patches, they are our patches, they are part of the
>project.
>> > And it's not unusual for multiple people working on a patch series;
>oneperson
>> > doing most of the work, another adding tests, another cleaning
>updocumentation.
>> > It's also no unheard of from a person picking up a patch series
>somebody else
>> > stopped working on.
>> 
>> This, of course, would be the _other_ case where a proposal's
>> merits are already known and accepted by the community.
>
>No. John might have sent a patch series X, and maybe he didn't explain
>correctly how it would benefit the project. Later on Mark finds out how
>those
>patches would be useful for himself and takes upon himself to get them
>merged,
>so he cleans them up and send an updated version with a clear
>explanation of
>how they would be useful.
>
>It's still the same proposal X, but a different person and a different
>strategy
>to get them merged.
>
>In other words, the fact that the community has not yet accepted the
>merits of
>an approach doesn't mean that another person cannot champion it.

As addressed above.

>> The default may be wrong, you and I might agree that the default is
>> wrong, Junio and Torvalds and RMS and The Queen of England
>> might all agree that the default is wrong... But if we all live
>across
>> from a bread shop, it's going to be a difficult task for you to
>convince
>> us to go hunting.
>
>It doesn't matter if you want to go hunting and I want to buy bread,
>either one
>of those is better than starving to death.
>
>In the Git project though, we choose to starve to death. Neither were
>my
>patches picked, nor did anybody else step up with a different proposal,
>we just
>did nothing, which is what we always do.

Not at all. Hunting may necessitate a negative side
effect, such as betraying vegetarianism,  having to go out
into the jungle for five days,  risk life and limb,  and (worse
yet) sleep in a tent. This is an especially poor decision if we
honestly would prefer a loaf of bread, and we just need to find
a way across the street.

And again, I'm referring to the general case here, but of your
views of what the solution should be clash with what the
community view is, you're not going to be able to convince
the community to go hunting. To tie in with the above, you
sure aren't going to be able to if you don't engage in logical,
calm, reasonable discourse.

Regards,
James.

Re: Recording the current branch on each commit?

[Felipe Contreras]

James Denholm wrote:

> You cannot expect that anybody but yourself is willing to propose,
> debate the merits of and otherwise defend patches that you have
> authored (herein "your patches", implying authorship, not
> ownership).

This is the original comment:

> David Kastrup wrote:
> > It becomes easier to actually change things when communicating in
> > a less abrasive and destructive manner.

Which is demonstrably false, as I already explained nobody else could
get these patches in, regarldless of the abrasiveness, or lack
thereof.

My point was that my abrasiveness is not an excuse not to do the
changes, as somebody else could get them in (or a similar proposal).
But they couldn't, because it's a change.

Your point about me not expecting somebody else to defend my patches
is irrelevant; it doesn't have anything to do with the topic, and it's
not relevant in general either.

I didn't ask or expect anybody to defend my patches, my point was that
David Kastrup was wrong; it wouldn't be easier to change things;
because change is simply not welcome.

> Ultimately, the only person who can ensure that a patch is
> championed, and the only person who need feel a responsibility to,
> is the author, and that responsibility is only ever to themselves.

Contributors don't have any responsibility to champion their patches.
It is pro bono work.

I should champion my patches because I want to improve Git, not
because I have a responsibility. And nobody else has any
responsibility either, but if somebody else want to improve Git as
well, they should chamption the patches (or others of their own) as
well.

In the meantime the problem still remains.

> > It doesn't matter if you want to go hunting and I want to buy
> > bread, either one of those is better than starving to death.
> 
> Not at all. Hunting may necessitate a negative side effect, such as
> betraying vegetarianism,  having to go out into the jungle for five
> days,  risk life and limb,  and (worse yet) sleep in a tent. This is
> an especially poor decision if we honestly would prefer a loaf of
> bread, and we just need to find a way across the street.

You obviously didn't read what I said.

> And again, I'm referring to the general case here, but of your
> views of what the solution should be clash with what the
> community view is, you're not going to be able to convince
> the community to go hunting.

I'm not going to convince them to buy bread either.

The community wants to starve to death, and you couldn't convince them
otherwise either.

-- 
Felipe Contreras

Re: Recording the current branch on each commit?

[David Kastrup]

Felipe Contreras <felipe.contreras@gmail.com> writes:

> Contributors don't have any responsibility to champion their patches.
> It is pro bono work.

No, that's just the appearance that should be upheld in the higher
society.  It's ok to get paid for work on Git as long as you don't
mention it in public.  It's also ok to get paid for _promises_ of work
if you can make people believe you.  Open Source is not much different
from how politics and society in general work in the U.S.A.  To get the
real wads of money, you first need to get the means not to have to talk
about money (it's ok if you do it by means totally opposed to "the
political cause" as long as you don't talk about it), then you have to
prefinance people's trust in you not being there for the money, and then
you are in a position to get paid for your work.

Anyway, I digress.  Even without all that not so "pro bono" background
to "pro bono work", there is still a difference between "pro bono" work
ending up in the wastebin and "pro bono" work ending up in a product.

Even while the ones getting the benefits from your work will not feel an
obligation to make it worth your while, there is a difference in
satisfaction between getting your work trashed and getting it used.

The satisfaction by exploding in self-righteousness tends to be a poor
substitute and is comparatively short-lived.

Yes, it may mean that you have to carry your child the last yards rather
than shout it across the finishing line.  Even though it should have
legs perfectly suited to get it across the track on its own.

Only that way you get to pat it on its head.

-- 
David Kastrup

Re: Recording the current branch on each commit?

[Felipe Contreras]

David Kastrup wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
> 
> > Contributors don't have any responsibility to champion their
> > patches.  It is pro bono work.
> 
> No, that's just the appearance that should be upheld in the higher
> society.  It's ok to get paid for work on Git as long as you don't
> mention it in public.

The word "contribute" implies doing something that was not necessary.
If somebody is paying you to do something, then it's not a
contribution, it is simply your duty.

That's why I used the word "contributors", to separate the people that
don't have a responsability, and the ones that do.

> Even while the ones getting the benefits from your work will not
> feel an obligation to make it worth your while, there is a
> difference in satisfaction between getting your work trashed and
> getting it used.

I don't know why this keeps poping up in the thread, but it is
starting to seem to me that you are under the impression that I'm
somehow unable to get my patches merged.

Look at the list of contributors of the past year, see who is #2:

https://www.ohloh.net/p/git/contributors?query=&sort=commits_12_mo

I know what kind of patches can get in, and what patches can't (the
ones that do any kind of relevant change). I know that from
experience.

-- 
Felipe Contreras

Re: Recording the current branch on each commit?

[David Kastrup]

Felipe Contreras <felipe.contreras@gmail.com> writes:

> David Kastrup wrote:
>
>> Even while the ones getting the benefits from your work will not
>> feel an obligation to make it worth your while, there is a
>> difference in satisfaction between getting your work trashed and
>> getting it used.
>
> I don't know why this keeps poping up in the thread, but it is
> starting to seem to me that you are under the impression that I'm
> somehow unable to get my patches merged.
>
> Look at the list of contributors of the past year, see who is #2:
>
> https://www.ohloh.net/p/git/contributors?query=&sort=commits_12_mo
>
> I know what kind of patches can get in, and what patches can't (the
> ones that do any kind of relevant change). I know that from
> experience.

Well, there you have it.  The ones that do any kind of relevant change
are the ones that need thinking about and consideration.  And when you
are so verbose about them that

a) you are getting on people's nerves
b) nobody else finds something worth saying that you did not already say

then the net effect is that it feels to the person in question he's
mainly doing you (and not all that many others) a favor by investing the
work for properly considering it and its consequences.

Which is not much of an incentive.  At any rate, we are in a phase
supposed to be shortly before the release of 2.0.  So it is actually
quite by design that patches doing any kind of relevant changes are not
currently going through.  You can be as nice or ugly about it as you
want right now and it will not affect 2.0 any more.

But it might do so regarding 2.1.

-- 
David Kastrup

Re: Recording the current branch on each commit?

[Felipe Contreras]

David Kastrup wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
> 
> > David Kastrup wrote:
> >
> >> Even while the ones getting the benefits from your work will not
> >> feel an obligation to make it worth your while, there is a
> >> difference in satisfaction between getting your work trashed and
> >> getting it used.
> >
> > I don't know why this keeps poping up in the thread, but it is
> > starting to seem to me that you are under the impression that I'm
> > somehow unable to get my patches merged.
> >
> > Look at the list of contributors of the past year, see who is #2:
> >
> > https://www.ohloh.net/p/git/contributors?query=&sort=commits_12_mo
> >
> > I know what kind of patches can get in, and what patches can't (the
> > ones that do any kind of relevant change). I know that from
> > experience.
> 
> Well, there you have it.  The ones that do any kind of relevant change
> are the ones that need thinking about and consideration.  And when you
> are so verbose about them that
> 
> a) you are getting on people's nerves
> b) nobody else finds something worth saying that you did not already say
> 
> then the net effect is that it feels to the person in question he's
> mainly doing you (and not all that many others) a favor by investing the
> work for properly considering it and its consequences.

This is the last time I say it: this is demonstrably false.

You claim that relevant changes can be made if the submitter is not so verbose
(and less aggressive and what not).

This is obviously not the case. Show me any change of importance done in the
last two years, hell, make it four. And by change I mean something that was one
way before, and was another way after.

There is nothing. It doesn't matter how these changes are presented. Changes
are not welcome, doesn't matter who is championing them, or how. Period.

> At any rate, we are in a phase supposed to be shortly before the release of
> 2.0.

This is a red herring. All the patches I'm talking about were sent well before
2.0 was imminent, six months to one year ago.

Even more, I'm challenging you to find an important change since even four years
ago. You won't find any.

> But it might do so regarding 2.1.

No, it won't. Neither 3.0.

-- 
Felipe Contreras

Re: Recording the current branch on each commit?

[David Kastrup]

Felipe Contreras <felipe.contreras@gmail.com> writes:

> David Kastrup wrote:
>
>> Well, there you have it.  The ones that do any kind of relevant change
>> are the ones that need thinking about and consideration.  And when you
>> are so verbose about them that
>> 
>> a) you are getting on people's nerves
>> b) nobody else finds something worth saying that you did not already say
>> 
>> then the net effect is that it feels to the person in question he's
>> mainly doing you (and not all that many others) a favor by investing
>> the work for properly considering it and its consequences.
>
> This is the last time I say it: this is demonstrably false.

Feelings are not categorizable as "demonstrably false".

> You claim that relevant changes can be made if the submitter is not so
> verbose (and less aggressive and what not).
>
> This is obviously not the case. Show me any change of importance done
> in the last two years, hell, make it four. And by change I mean
> something that was one way before, and was another way after.

The default behavior of "git push".  Colorized diffs.  "git add dir/"
can now remove files.  "git gc --aggressive" has been sanitized.

-- 
David Kastrup

Re: Recording the current branch on each commit?

[Felipe Contreras]

David Kastrup wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
> 
> > David Kastrup wrote:
> >
> >> Well, there you have it.  The ones that do any kind of relevant change
> >> are the ones that need thinking about and consideration.  And when you
> >> are so verbose about them that
> >> 
> >> a) you are getting on people's nerves
> >> b) nobody else finds something worth saying that you did not already say
> >> 
> >> then the net effect is that it feels to the person in question he's
> >> mainly doing you (and not all that many others) a favor by investing
> >> the work for properly considering it and its consequences.
> >
> > This is the last time I say it: this is demonstrably false.
> 
> Feelings are not categorizable as "demonstrably false".

It's demonsrable by the challenge below.

> > You claim that relevant changes can be made if the submitter is not so
> > verbose (and less aggressive and what not).
> >
> > This is obviously not the case. Show me any change of importance done
> > in the last two years, hell, make it four. And by change I mean
> > something that was one way before, and was another way after.
> 
> The default behavior of "git push".

This is a minor change that not many people would notice, and it has not
actually happend. But fine, let's count it as one.

> Colorized diffs.

That's not a change.

> "git add dir/"

That doesn't count as an important change.

> can now remove files.

Irrelevant.

> "git gc --aggressive" has been sanitized.

Irrelevant. Nobody did notice.


That's all you could list for *four* years? None of that would even be noticed
by most of our users, maybe push.default (when it actually happens), but that's
*one*.

*One* important change in *four* years.

That's demonstration that change just does not happen. And if you disagree,
then we'll agree to disagree.

-- 
Felipe Contreras

Re: Recording the current branch on each commit?

[David Kastrup]

Felipe Contreras <felipe.contreras@gmail.com> writes:

> David Kastrup wrote:
>
>> The default behavior of "git push".
>
> This is a minor change that not many people would notice, and it has not
> actually happend. But fine, let's count it as one.

Shrug.  Your diatribe is to a good part about the default behavior of
"git pull".  The "minor" change affects multiple branches in upstream,
while your "important change" affects a single local branch.

With that sort of bias, it's easy to convince yourself of anything.

-- 
David Kastrup

Re: Recording the current branch on each commit?

[Felipe Contreras]

David Kastrup wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
> 
> > David Kastrup wrote:
> >
> >> The default behavior of "git push".
> >
> > This is a minor change that not many people would notice, and it has not
> > actually happend. But fine, let's count it as one.
> 
> Shrug.  Your diatribe is to a good part about the default behavior of
> "git pull".

> The "minor" change affects multiple branches in upstream,

This is what most people see by default since two years ago:

  warning: push.default is unset; its implicit value is changing in
  Git 2.0 from 'matching' to 'simple'. To squelch this message
  and maintain the current behavior after the default changes, use:

    git config --global push.default matching

  To squelch this message and adopt the new behavior now, use:

    git config --global push.default simple

  When push.default is set to 'matching', git will push local branches
  to the remote branches that already exist with the same name.

  In Git 2.0, Git will default to the more conservative 'simple'
  behavior, which only pushes the current branch to the corresponding
  remote branch that 'git pull' uses to update the current branch.

  See 'git help config' and search for 'push.default' for further information.
  (the 'simple' mode was introduced in Git 1.7.11. Use the similar mode
  'current' instead of 'simple' if you sometimes use older versions of Git)

Do you honestly believe that there's *anybody* out there is OK with seeing this
message _every_ _single_ _time_ he pushes? No. Everybody has already configured
push.default to one thing or the other. They won't see the change when 2.0 is
released.

And no, if by some miracle somebody hasn't configured that, it still won't
affect the branches upstream, if anything changes is that the `git pull` will
error out warning the user that the upstream branch doesn't have the same name.
It won't affect the branches you actually push.

> while your "important change" affects a single local branch.

My change does actually affect upstream branches, more than that, it affects
the upstream topology, because Git newcomers make merges by mistake when they
call `git pull` without knowing what the hell is going on. Everybody knows
that.

And this is a red herring. I never said my change was important, we are talking
about the changes that have actually happened in the last four years, which is
none.

> With that sort of bias, it's easy to convince yourself of anything.

I'm done discussing with you. I already demonstrated that your claim is wrong.
Change just doesn't happen.

-- 
Felipe Contreras

Re: Recording the current branch on each commit?

[James Denholm]

I've no right to say this, given that I've no contributions
thus far to the project, little history in open source at all,
and have only been following the list for less than a week,
but I'll say it anyway, mayhaps.

And I don't mean this to cause offence, or inspire outrage,
or any similar sort of thing. I mean this only with good
intentions.

But Felipe, if you honestly feel that git has stagnated, and
that your contributions aren't wanted because we'd
rather starve, then perhaps git isn't the right project for you.

I'm not saying that you shouldn't work on the git codebase,
you could very easily fork it and make the innovative SCMS
none of us can see, and kill git. Can be done, if hunting really
is the best choice as you say.

Re: Recording the current branch on each commit?

[Felipe Contreras]

James Denholm wrote:
> I've no right to say this, given that I've no contributions I'm not
> saying that you shouldn't work on the git codebase, you could very
> easily fork it and make the innovative SCMS none of us can see, and
> kill git. Can be done, if hunting really is the best choice as you
> say.

I already made a fork:

http://felipec.wordpress.com/2013/10/28/git-fc/

-- 
Felipe Contreras

Re: Recording the current branch on each commit?

[James Denholm]

On 29 April 2014 21:47:42 GMT+10:00, Felipe Contreras <felipe.contreras@gmail.com> wrote:
>James Denholm wrote:
>> I've no right to say this, given that I've no contributions I'm not
>> saying that you shouldn't work on the git codebase, you could very
>> easily fork it and make the innovative SCMS none of us can see, and
>> kill git. Can be done, if hunting really is the best choice as you
>> say.
>
>I already made a fork:
>
>http://felipec.wordpress.com/2013/10/28/git-fc/

Sweet. So now you're going to get open source journalism
interested in git-fc and gain a groundswell of support, right?
So that we can all have egg on our faces when it takes off
and is proven superior... Right?

Re: Recording the current branch on each commit?

[Felipe Contreras]

James Denholm wrote:
> So that we can all have egg on our faces when it takes off and is
> proven superior... Right?

I don't know what you mean by "we", but it certainly doesn't include
you.

  % git log --author=nod.helm@gmail.com master
  empty

-- 
Felipe Contreras

Re: Recording the current branch on each commit?

[James Denholm]

On 29 April 2014 23:31:29 GMT+10:00, Felipe Contreras <felipe.contreras@gmail.com> wrote:
>James Denholm wrote:
>> So that we can all have egg on our faces when it takes off and is
>> proven superior... Right?
>
>I don't know what you mean by "we", but it certainly doesn't include
>you.
>
>  % git log --author=nod.helm@gmail.com master
>  empty

Sure it does. I didn't (and don't) have any impact on the
debate and resulting community views, but I recall recently
that I prescribed to the arguments that default aliases
are a bad idea. I'm not arrogant enough to suggest that
my views matter at this point, but if git-fc is proven superior
by community adoption, I would be as wrong as anyone else
who held that view.

So I'll ask again - you've described frustration at the
pace of git development, and that you feel that your patches
aren't being accepted. If you feel that this is ultimately to the
fatal detriment of git, why are you still trying to convince
vegetarians to join you in hunting when you could simply find
a more willing group?

Regards,
James Denholm.

Re: Recording the current branch on each commit?

[Felipe Contreras]

James Denholm wrote:
> On 29 April 2014 23:31:29 GMT+10:00, Felipe Contreras <felipe.contreras@gmail.com> wrote:
> >James Denholm wrote:
> >> So that we can all have egg on our faces when it takes off and is
> >> proven superior... Right?
> >
> >I don't know what you mean by "we", but it certainly doesn't include
> >you.
> >
> >  % git log --author=nod.helm@gmail.com master
> >  empty
> 
> Sure it does.

No it doesn't. Unless you have some credentials in the Git community,
which come after several contributions, your opinion carries no weight
at all. This might not be ideal, but that's the way it is.

You have no credentials, your opinion doesn't count. You are not part of
the "we" you referred before.

> So I'll ask again - you've described frustration at the
> pace of git development, and that you feel that your patches
> aren't being accepted. If you feel that this is ultimately to the
> fatal detriment of git, why are you still trying to convince
> vegetarians to join you in hunting when you could simply find
> a more willing group?

If by convince you mean apply my patches, my patches are still getting
applied [1].

Either way your analogy is completely wrong as I already explained
multiple times. I'm not trying to convince vegetarians to go hunting,
I'm saying they should eat something, bread, meat, vegetables, anything.
Instead they choose to starve to death.

And I'm done discussing with you. Your comments are content-free.

[1] https://www.ohloh.net/p/git/contributors?sort=latest_commit

-- 
Felipe Contreras

Re: Recording the current branch on each commit?

[James Denholm]

On 30 April 2014 07:45:37 GMT+10:00, Felipe Contreras <felipe.contreras@gmail.com> wrote:
>James Denholm wrote:
>> On 29 April 2014 23:31:29 GMT+10:00, Felipe Contreras
><felipe.contreras@gmail.com> wrote:
>> >James Denholm wrote:
>> >> So that we can all have egg on our faces when it takes off and is
>> >> proven superior... Right?
>> >
>> >I don't know what you mean by "we", but it certainly doesn't include
>> >you.
>> >
>> >  % git log --author=nod.helm@gmail.com master
>> >  empty
>> 
>> Sure it does.
>
>No it doesn't. Unless you have some credentials in the Git community,
>which come after several contributions, your opinion carries no weight
>at all. This might not be ideal, but that's the way it is.
>
>You have no credentials, your opinion doesn't count. You are not part
>of
>the "we" you referred before.

I find your lack of reading comprehension... disturbing.

To reassert the my full statement, as you so hastily truncated:

>James Denholm wrote:
> Sure it does. I didn't (and don't) have any impact on the
> debate and resulting community views, but I recall recently
> that I prescribed to the arguments that default aliases
> are a bad idea. I'm not arrogant enough to suggest that
> my views matter at this point, but if git-fc is proven superior
> by community adoption, I would be as wrong  as anyone else
> who held that view.

>> So I'll ask again - you've described frustration at the
>> pace of git development, and that you feel that your patches
>> aren't being accepted. If you feel that this is ultimately to the
>> fatal detriment of git, why are you still trying to convince
>> vegetarians to join you in hunting when you could simply find
>> a more willing group?
>
>If by convince you mean apply my patches, my patches are still getting
>applied [1].
>
> (...)
>
>[1] https://www.ohloh.net/p/git/contributors?sort=latest_commit

But that isn't the case. If it was, you wouldn't have a blog post
up about how git-fc has default aliases (and such), while git
does not. You wouldn't have another post exclaiming
frustration at the pace of development, and how certain
contributions of yours have been ignored.

Sure, a subset of your patches are being accepted, but if
the ones you cared about weren't, this discussion
wouldn't have even occurred.

>Either way your analogy is completely wrong as I already explained
>multiple times. I'm not trying to convince vegetarians to go hunting,
>I'm saying they should eat something, bread, meat, vegetables,
>anything.
>Instead they choose to starve to death.

Not at all. You propose solutions, rather than *just* calling
for any solution to be accepted. I'm the meantime, the
community decides that some of your proposals
aren't good ideas, and decide to consider others in due
course.

>And I'm done discussing with you. Your comments are content-free.

Only code-free. And that's because this is a people problem,
Felipe, not a code problem.

Regards,
James Denholm.

Re: Recording the current branch on each commit?

[Felipe Contreras]

James Denholm wrote:
> > Either way your analogy is completely wrong as I already explained
> > multiple times. I'm not trying to convince vegetarians to go
> > hunting, I'm saying they should eat something, bread, meat,
> > vegetables, anything. Instead they choose to starve to death.
> 
> I'm the meantime, the community decides that some of your proposals
> aren't good ideas, and decide to consider others in due course.

Wrong. The problems are ackowledged, no other proposals are put forward,
nothing gets done.

-- 
Felipe Contreras

Re: Recording the current branch on each commit?

[James Denholm]

Felipe Contreras wrote:
> James Denholm wrote:
>> > Either way your analogy is completely wrong as I already explained
>> > multiple times. I'm not trying to convince vegetarians to go
>> > hunting, I'm saying they should eat something, bread, meat,
>> > vegetables, anything. Instead they choose to starve to death.
>>
>> I'm the meantime, the community decides that some of your proposals
>> aren't good ideas, and decide to consider others in due course.
>
> Wrong. The problems are ackowledged, no other proposals are put forward,
> nothing gets done.

So I'll ask again - you've described frustration at the
pace of git development, and that you feel that your patches
aren't being accepted. If you feel that this is ultimately to the
fatal detriment of git, why are you still trying to convince
vegetarians to join you in hunting when you could simply find
a more willing group?

Re: Recording the current branch on each commit?

[Felipe Contreras]

James Denholm wrote:
> Felipe Contreras wrote:
> > James Denholm wrote:
> >> > Either way your analogy is completely wrong as I already explained
> >> > multiple times. I'm not trying to convince vegetarians to go
> >> > hunting, I'm saying they should eat something, bread, meat,
> >> > vegetables, anything. Instead they choose to starve to death.
> >>
> >> I'm the meantime, the community decides that some of your proposals
> >> aren't good ideas, and decide to consider others in due course.
> >
> > Wrong. The problems are ackowledged, no other proposals are put forward,
> > nothing gets done.
> 
> So I'll ask again - you've described frustration at the
> pace of git development, and that you feel that your patches
> aren't being accepted. If you feel that this is ultimately to the
> fatal detriment of git, why are you still trying to convince
> vegetarians to join you in hunting when you could simply find
> a more willing group?

You are obviously not very good with analogies, or reading for that
matter. The answer is quoted right in the begginning of the mail.
Congratulations, you've achieved a mail quote loop.

-- 
Felipe Contreras

Re: Recording the current branch on each commit?

[James Denholm]

Felipe Contreras wrote:
> You are obviously not very good with analogies, or reading for that
> matter. The answer is quoted right in the begginning of the mail.
> Congratulations, you've achieved a mail quote loop.

I'll rephrase the question and it's context. Please attempt to answer
it.

You've expressed frustration at the pace of git's development.

You've expressed frustration at how your proposals, at least a subset
thereof, are not being chosen as solutions.

You've expressed belief that this is to the fatal detriment of git.

And you've expressed that you believe this situation won't change.

Given that you feel you have the necessary solutions and you have
git-fc with which to drive them into the world, why are you sticking
around expressing exasperation and inevitable fatality? Why not
promote git-fc as the superior option, as upon it's succession of git
you would have the argument needed to back your proposals?

Regards,
James Denholm.

Re: Recording the current branch on each commit?

[Piotr Krukowiecki]

On Tue, Apr 29, 2014 at 12:17 PM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> That's all you could list for *four* years? None of that would even be noticed
> by most of our users, maybe push.default (when it actually happens), but that's
> *one*.
>
> *One* important change in *four* years.

Hi,

one out of how many? (How many proposed important changes were rejected?)

Thanks,
-- 
Piotr Krukowiecki

Re: Recording the current branch on each commit?

[Robin Rosenberg]

----- Ursprungligt meddelande -----
> Från: "Felipe Contreras" <felipe.contreras@gmail.com>
> Till: "James Denholm" <nod.helm@gmail.com>, "Felipe Contreras" <felipe.contreras@gmail.com>
> Kopia: "David Kastrup" <dak@gnu.org>, "Jeremy Morton" <admin@game-point.net>, "Johan Herland" <johan@herland.net>,
> "Git mailing list" <git@vger.kernel.org>
> Skickat: tisdag, 29 apr 2014 5:32:29
> Ämne: Re: Recording the current branch on each commit?
> 
> James Denholm wrote:
> > Felipe Contreras <felipe.contreras@gmail.com> wrote:
> > > James Denholm wrote:
> > >> It's not anybody else's job to take your patches and drizzle them in the
> > >> honey of respectable discourse.
> > >
> > > It's nobody's job to do anything. This a collaborative effort and in a
> > > collaborative effort everbody chimes in to do different things.
[...]

> In the Git project though, we choose to starve to death. Neither were my
> patches picked, nor did anybody else step up with a different proposal, we
> just
> did nothing, which is what we always do.

Just because you are starving, the others may not be. I'll skip dinner today.

Not all people view the world the same way you do. Sometimes they don't "see it" 
because they don't share your experience. A year later other people may have come to the
same conclusion as you (or not) and whatever the idea you had may come
from someone else, when the world is ready. 

Whining won't help, it will just reduce your credibility, perhaps to the point
that people won't even read a improved proposal if you come up with one.

Remember this is a high volume list, so you don't get much time to explain an idea. It's
a matter of karma.

-- robin

Re: Recording the current branch on each commit?

[Sitaram Chamarty]

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

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

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

Re: Recording the current branch on each commit?

[Jeremy Morton]

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)

Re: Recording the current branch on each commit?

[Sitaram Chamarty]

On 04/28/2014 02:22 PM, Jeremy Morton wrote:
> 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?

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

Re: Recording the current branch on each commit?

[David Kastrup]

Johan Herland <johan@herland.net> 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

Re: Recording the current branch on each commit?

[Sitaram Chamarty]

On 04/28/2014 11:37 AM, David Kastrup wrote:
> Johan Herland <johan@herland.net> 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.

Johan: I seem to have missed your previous email (fat-fingered something
on my mail client I expect).

Your **reasons** for making it optional are all wrong.  People like me
(and David) who are opposed to this run the risk that if the **format**
were to officially change in some way or for some reason (like, say, if
SHA1 is no longer in favour, or whatever), then this "feature" is
foisted on us willy-nilly.

That's not good.

So, while I appreciate your point that it should be optional, please
let's accept that in the end it should be optional because **not
everyone likes it**!

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

Hear hear!!

Re: Recording the current branch on each commit?

[Johan Herland]

On Mon, Apr 28, 2014 at 12:03 PM, Sitaram Chamarty <sitaramc@gmail.com> wrote:
>> Johan Herland <johan@herland.net> 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.
>
> Johan: I seem to have missed your previous email (fat-fingered something
> on my mail client I expect).
>
> Your **reasons** for making it optional are all wrong.  People like me
> (and David) who are opposed to this run the risk that if the **format**
> were to officially change in some way or for some reason (like, say, if
> SHA1 is no longer in favour, or whatever), then this "feature" is
> foisted on us willy-nilly.
>
> That's not good.
>
> So, while I appreciate your point that it should be optional, please
> let's accept that in the end it should be optional because **not
> everyone likes it**!

You may have missed more than just one previous email... I tried (but
obviously failed) to make it clear from the start that I personally
don't support this feature (although, as long as it's optional I'm
mostly indifferent to it).

Trying to steer the discussion towards a constructive end, I then
argued that even IF we were to agree that this was a good change (and
this thread CLEARLY demonstrates that we DO NOT agree), it would STILL
be better to first implement this change within the confines of the
existing object model, without making any changes to Git itself.

Having done an initial implementation "outside" of the git core (which
should be fairly straightforward with hooks + git-interpret-trailers),
Jeremy would have gotten the feature he wanted (or at least a close
approximation), and we could then observe if this feature became
popular/useful enough to consider integrating it into core Git.

So, the only constructive way forward (whether we like the feature or
not) is for Jeremy (or someone else) to first implement it "outside"
the Git core.

THIS is my point, and I really, REALLY tried to explain it while
AVOIDING the inevitable flamewar about what "belongs" in a commit
object or not. It's not that I don't have an opinion on that subject;
it's that everybody has their own opinion, and it's largely a
philosophical discussion that boils down to peoples workflows,
preferences, backgrounds, and whatnot. As such, it's perfect material
for the flamewar we're currently observing...


...Johan

-- 
Johan Herland, <johan@herland.net>
www.herland.net

Re: Recording the current branch on each commit?

[Felipe Contreras]

Johan Herland wrote:
> On Sun, Apr 27, 2014 at 7:38 PM, Jeremy Morton <admin@game-point.net> wrote:
> > 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

Re: Recording the current branch on each commit?

[Felipe Contreras]

Jeremy Morton wrote:
> On 27/04/2014 10:09, Johan Herland wrote:
> > On Sun, Apr 27, 2014 at 1:56 AM, Jeremy Morton<admin@game-point.net>  wrote:
> >> Currently, git records a checksum, author, commit date/time, and commit
> >> message with every commit (as get be seen from 'git log').  I think it would
> >> be useful if, along with the Author and Date, git recorded the name of the
> >> current branch on each commit.
> >
> > This has been discussed multiple times in the past. One example here:
> > http://thread.gmane.org/gmane.comp.version-control.git/229422
> >
> > I believe the current conclusion (if any) is that encoding such
> > information as a _structural_ part of the commit object is not useful.
> > See the old thread(s) for the actual pro/con arguments.
> 
> As far as I can tell from that discussion, the general opposition to 
> encoding the branch name as a structural part of the commit object is 
> that, for some people's workflows, it would be unhelpful and/or 
> misleading.

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

RE: Recording the current branch on each commit?

[Max Kirillov]

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

Re: Recording the current branch on each commit?

[Junio C Hamano]

"Max Kirillov" <max@max630.net> 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.
>
> 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?

We had lengthy discussions in early 2010 [*1*].  The whole thread,
at least the whole sub-thread that contains the focused message, is
a required reading to understand where we stand with respect to
"extra headers in commit objects".

"Any additional information about the commit can be added" you
suggest is exactly the kind of thing we want to avoid, which made
Linus say in an even older discussion [*2*]:

    No "this random field could be used this random way" crud,
    please.


[References]

*1* http://thread.gmane.org/gmane.comp.version-control.git/138848/focus=138892
*2* http://thread.gmane.org/gmane.comp.version-control.git/19126/focus=19149

Re: Recording the current branch on each commit?

[Max Kirillov]

On Mon, Apr 28, 2014 at 11:15:10AM -0700, Junio C Hamano wrote:
> "Any additional information about the commit can be added" you
> suggest is exactly the kind of thing we want to avoid, which made
> Linus say in an even older discussion [*2*]:
> 
>     No "this random field could be used this random way" crud,
>     please.

I see, thanks for explanation.

-- 
Max

RE: Recording the current branch on each commit?

[Max Kirillov]

> 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