Feature request: "author branch" in commit object

Feature request: "author branch" in commit object

[Ed Hutchins]

I realize that branch names are ephemeral repo-specific things, but it
would be really useful to be able to determine what branch a commit
was authored from (as a hint to ancestry graph layout tools, for
example). Is there any way to do this currently, is it planned, or
would it be deemed useful enough to be worth adding to each commit
object?

  - Ed

Re: Feature request: "author branch" in commit object

[Fredrik Gustafsson]

On Tue, Jul 02, 2013 at 12:37:13PM -0700, Ed Hutchins wrote:
> I realize that branch names are ephemeral repo-specific things, but it
> would be really useful to be able to determine what branch a commit
> was authored from (as a hint to ancestry graph layout tools, for
> example). Is there any way to do this currently, is it planned, or
> would it be deemed useful enough to be worth adding to each commit
> object?

Let's see if I understand you. You want to (for each commit) to be able
to tell the branch-name the commit had at the creation time?

Not all commits have branches (however, loose commits is usually not
wanted). Many commits are part of many branches.

A branch is not a collection of commits but a pointer to a commit (which
has parents).

-- 
Med vänliga hälsningar
Fredrik Gustafsson

tel: 0733-608274
e-post: iveqy@iveqy.com

Re: Feature request: "author branch" in commit object

[Junio C Hamano]

Ed Hutchins <eh@demeterr.com> writes:

> I realize that branch names are ephemeral repo-specific things, but it
> would be really useful to be able to determine what branch a commit
> was authored from (as a hint to ancestry graph layout tools, for
> example).

Hmm.  I think the current thinking so far is that it is harmful to
engrave that information in the commit object, exactly for the
reason you stated upfront: these names are local in the repository
the commit was created, and do not have any global meaning.

> Is there any way to do this currently, is it planned, or
> would it be deemed useful enough to be worth adding to each commit
> object?

No, no, and no, not because it is not just useful enough but it may
be actively harmful.

Re: Feature request: "author branch" in commit object

[Ed Hutchins]

I'm not sure I follow how it could be actively harmful? I would think
the "author branch"
nomenclature (as opposed to just calling it "branch") along with clear
documentation
that these values are just captures of the particular state the commit
was authored
from would more than assuage any potential misuse. On the other hand
trying to figure
out the history of events from a large directed graph of commits
without any clue about
what topics first spawned each commit is actively harmful in many
cases (trying to display
a clear history of who did what for what reasons, for example).




On Tue, Jul 2, 2013 at 1:00 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Ed Hutchins <eh@demeterr.com> writes:
>
>> I realize that branch names are ephemeral repo-specific things, but it
>> would be really useful to be able to determine what branch a commit
>> was authored from (as a hint to ancestry graph layout tools, for
>> example).
>
> Hmm.  I think the current thinking so far is that it is harmful to
> engrave that information in the commit object, exactly for the
> reason you stated upfront: these names are local in the repository
> the commit was created, and do not have any global meaning.
>
>> Is there any way to do this currently, is it planned, or
>> would it be deemed useful enough to be worth adding to each commit
>> object?
>
> No, no, and no, not because it is not just useful enough but it may
> be actively harmful.

Re: Feature request: "author branch" in commit object

[Antoine Pelisse]

On Tue, Jul 2, 2013 at 10:34 PM, Ed Hutchins <eh@demeterr.com> wrote:
> On the other hand
> trying to figure
> out the history of events from a large directed graph of commits
> without any clue about
> what topics first spawned each commit is actively harmful in many
> cases (trying to display
> a clear history of who did what for what reasons, for example).

I think this is exactly what Junio does with git.git:
- Each branch is named "$initials/$topicname" before being merged.
- Branches are always merged with --no-ff.

I think it answers your question: Who (initials) does what (topic)
The name of the branch is also stuck as part of the history as the
merge reads the name of the merged branch:

e.g. Merge branch 'rr/remote-branch-config-refresh'

You can of course provide more information than the simple commit
header line (that would give the "what reasons").

Of course, it's even easier to read if you always merge in the same
direction (that allows you to easily find the first commit of the
branch).

Hope that helps,
Antoine

Re: Feature request: "author branch" in commit object

[Ed Hutchins]

I might be able to switch our corporate workflow to adding non-ff merge
commits, but the reason we moved away from using github's big red button
in the first place was to avoid the extra noise of merge-only commits.

Actually you've pointed out an inconsistency: why is it okay for merge
commits to automatically mention branch names, but for regular commits
this is considered harmful?

On Wed, Jul 3, 2013 at 9:16 AM, Antoine Pelisse <apelisse@gmail.com> wrote:
> On Tue, Jul 2, 2013 at 10:34 PM, Ed Hutchins <eh@demeterr.com> wrote:
>> On the other hand
>> trying to figure
>> out the history of events from a large directed graph of commits
>> without any clue about
>> what topics first spawned each commit is actively harmful in many
>> cases (trying to display
>> a clear history of who did what for what reasons, for example).
>
> I think this is exactly what Junio does with git.git:
> - Each branch is named "$initials/$topicname" before being merged.
> - Branches are always merged with --no-ff.
>
> I think it answers your question: Who (initials) does what (topic)
> The name of the branch is also stuck as part of the history as the
> merge reads the name of the merged branch:
>
> e.g. Merge branch 'rr/remote-branch-config-refresh'
>
> You can of course provide more information than the simple commit
> header line (that would give the "what reasons").
>
> Of course, it's even easier to read if you always merge in the same
> direction (that allows you to easily find the first commit of the
> branch).
>
> Hope that helps,
> Antoine

Re: Feature request: "author branch" in commit object

[Junio C Hamano]

Ed Hutchins <eh@demeterr.com> writes:

> I might be able to switch our corporate workflow to adding non-ff merge
> commits, but the reason we moved away from using github's big red button
> in the first place was to avoid the extra noise of merge-only commits.
>
> Actually you've pointed out an inconsistency: why is it okay for merge
> commits to automatically mention branch names, but for regular commits
> this is considered harmful?

We do not care what you write as part of human-readable payload.

Your local convention could be to add, near the end of your log
messages, "Made-on-branch: frotz" line, just like all the commits in
our project have "Signed-off-by: line" at the end.

The problem we avoid is to add it as structural part of the commit
object.

Re: Feature request: "author branch" in commit object

[Andrew Ardill]

On 4 July 2013 09:46, Jakub Narebski <jnareb@gmail.com> wrote:
> Junio C Hamano <gitster <at> pobox.com> writes:
>> It is not just misleading but is actively wrong to recording the
>> name of the original branch in commits and carrying them forward via
>> rebase. If you want a record of what a group of commits were about,
>> the right time to do so is when you merge.
>
> There is even git-resurrect.sh script in 'contrib/' that makes
> use of that practice to find merged-in and deleted branches,
> and resurrect them (among other tools).

How do users who wish to keep a record of branch names find out that
--no-ff will enable this behaviour?

Is this a common enough requirement to make --no-ff the default
behaviour (probably not, and that transition would be painful)?

What are the shortcomings of using --no-ff in the analogue to how
mercurials named branches work?

I think the git-flow and git-list style workflows have done a lot to
promote a set of usage patterns that keep this metadata around, I just
wonder if we can do more to assist users in what seems to be a
relatively common request.

Regards,

Andrew Ardill

Re: Feature request: "author branch" in commit object

[Johan Herland]

On Tue, Jul 2, 2013 at 9:37 PM, Ed Hutchins <eh@demeterr.com> wrote:
> I realize that branch names are ephemeral repo-specific things, but it
> would be really useful to be able to determine what branch a commit
> was authored from (as a hint to ancestry graph layout tools, for
> example). Is there any way to do this currently, is it planned, or
> would it be deemed useful enough to be worth adding to each commit
> object?

As Junio stated elsewhere in the thread: No.

However, you could do this with "git notes", which allows you to
attach information to a commit object without changing the commit
object itself. Of course, for this to work, you would have to write a
post-commit hook to record the branch information in a commit note,
and then convince all contributors in your project to install the same
hook. Then you'd need to teach the relevant graph layout tools to pay
attention to your notes.

...Johan

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

Re: Feature request: "author branch" in commit object

[Matthieu Moy]

Ed Hutchins <eh@demeterr.com> writes:

> I realize that branch names are ephemeral repo-specific things, but it
> would be really useful to be able to determine what branch a commit
> was authored from (as a hint to ancestry graph layout tools, for
> example). Is there any way to do this currently, is it planned, or
> would it be deemed useful enough to be worth adding to each commit
> object?

FWIW, this is what Mercurial's "named branches" do. Instead of having
branches point to commit, each commit says what branch it belongs to.

One drawback of this approach is that the branch name is part of the
commit and can't be changed without changing the commit's sha1. Hence, a
local, private, branch name becomes permanent the day it's merged
upstream.

(for completeness: Mercurial also has essentially Git-like branches,
but they call this "bookmarks")

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: Feature request: "author branch" in commit object

[Ed Hutchins]

I'm not trying to change the way git does things (which works perfectly
well), I'm asking for some extra information to be added to the commit
so that analysis of the ancestry graph can be tied to the branch topics
that the original author was working from. Currently if you have a
rebase-branch/ff-merge-to-master workflow, the graph of commits looks
like a single user produced all of the code. It would be very useful for
both forensic and display purposes to categorize those commits by their
original topics, but that history is lost in such a workflow. Certainly
there are work-arounds (notes etc.) to capture this history, but I think
that this is a basic feature which most projects would benefit from. I
fully understand that branches are not global and that it may be
confusing to keep an "author branch" name around in some cases, but the
vast majority of cases where authors pick meaningful branch names would
benefit from being able to look back and go "ah-ha! that was a commit to
fix bug such-and-such" or "that was a commit from when I was working on
super-cool feature X". Even just knowing that two commits were from
different (or the same) branches would tell you something useful about
the evolution of the project. Arguing that branch names are local and
thus meaningless misses the point: branches are *names* which were
meaningful to the author at the time the branch was being worked on.
Discarding this information makes it harder to reason about or display
the history of the project and is an irritating defect in an otherwise
wonderful tool.

On Wed, Jul 3, 2013 at 2:33 AM, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
> Ed Hutchins <eh@demeterr.com> writes:
>
>> I realize that branch names are ephemeral repo-specific things, but it
>> would be really useful to be able to determine what branch a commit
>> was authored from (as a hint to ancestry graph layout tools, for
>> example). Is there any way to do this currently, is it planned, or
>> would it be deemed useful enough to be worth adding to each commit
>> object?
>
> FWIW, this is what Mercurial's "named branches" do. Instead of having
> branches point to commit, each commit says what branch it belongs to.
>
> One drawback of this approach is that the branch name is part of the
> commit and can't be changed without changing the commit's sha1. Hence, a
> local, private, branch name becomes permanent the day it's merged
> upstream.
>
> (for completeness: Mercurial also has essentially Git-like branches,
> but they call this "bookmarks")
>
> --
> Matthieu Moy
> http://www-verimag.imag.fr/~moy/

Re: Feature request: "author branch" in commit object

[Junio C Hamano]

Ed Hutchins <eh@demeterr.com> writes:

> I'm not trying to change the way git does things (which works perfectly
> well), I'm asking for some extra information to be added to the commit
> so that analysis of the ancestry graph can be tied to the branch topics
> that the original author was working from. Currently if you have a
> rebase-branch/ff-merge-to-master workflow, the graph of commits looks
> like a single user produced all of the code. It would be very useful for
> both forensic and display purposes to categorize those commits by their
> original topics, but that history is lost in such a workflow.

I am not following that "a single user" part. As long as these
topics are done by different people, the authorship remains
separate, no matter what the shape of the graph is.

It all depends on what you show on the graph other than a circle and
connecting lines, but I presume at least you would show the subject
line. The graph would clearly show which groups of commits tackle
what problems in your history, even if you excessively linearlized
it by rebasing. You need subjects / commit log messages that are
better than "bugfix", of course, for it to work, though.

> Arguing that branch names are local and thus meaningless misses
> the point: branches are *names* which were meaningful to the
> author at the time the branch was being worked on.

That is not necessarily true.

Most of my commits start their life on a single branch that is named
after a very broad theme (or even on a detached HEAD) that ends up
touching different parts of the system and then later split into
separate topic branches that are named after more detailed single
issues. The name of the branch that happened to have been used to
create them have almost no meaning after I am done with multiple and
independent (but related in the larger scheme of things) topics.

It is not just misleading but is actively wrong to recording the
name of the original branch in commits and carrying them forward via
rebase. If you want a record of what a group of commits were about,
the right time to do so is when you merge.

Projects that care about the shape of the ancestry graph have an
obvious option of not excessively/unnecessarily linearlizing their
history. We even have the "--no-ff" mode of merge to create an
otherwise unnecessary merge to mark the point where a topic is
merged to the mainline, so that merge log messages can say what
topic was merged (and also you can even have "merge.log").

Cleaning up a messy history created on a topic branch before
presenting to others by lineralizing is one thing. It is a good
practice. Requiring any update to fast-forward on top of the tip of
the project is quite different. It does not make your history any
easier to read. A topic that has been working fine on top of last
week's trunk can have a subtle interaction with the work done by
others on the trunk since it forked, and rebasing it on top of
today's trunk, just before pushing it out on the trunk, risks
breaking the topic in a subtle way without the person who does such
a rebase without noticing, making later bisection harder.

Any option to encourage such an artificially linear history _is_
actively detrimental.

Re: Feature request:

[Jakub Narebski]

[I'm sorry about breaking Cc: chain - responding via GMane web interface]

Junio C Hamano <gitster <at> pobox.com> writes:
> Ed Hutchins <eh <at> demeterr.com> writes:
> 
> > I'm not trying to change the way git does things (which works perfectly
> > well), I'm asking for some extra information to be added to the commit
> > so that analysis of the ancestry graph can be tied to the branch topics
> > that the original author was working from. [...]
[...]
> It is not just misleading but is actively wrong to recording the
> name of the original branch in commits and carrying them forward via
> rebase. If you want a record of what a group of commits were about,
> the right time to do so is when you merge.
[...]

There is even git-resurrect.sh script in 'contrib/' that makes
use of that practice to find merged-in and deleted branches,
and resurrect them (among other tools).

-- 
Jakub Narębski

Re: Feature request:

[Dany]

Hey Jonathan,

Thanks for the quick reply. I think that's a great message; I do have to say that I wouldn't have known what the `matching` and `simple` modes are without that message; I just had to look it up is all. It may be helpful to tell users that `simple` is probably what they want :)

@DanyJoumaa
1 520 991 5001

On Jul 3, 2013, at 4:46 PM, Jakub Narebski <jnareb@gmail.com> wrote:

> [I'm sorry about breaking Cc: chain - responding via GMane web interface]
> 
> Junio C Hamano <gitster <at> pobox.com> writes:
>> Ed Hutchins <eh <at> demeterr.com> writes:
>> 
>>> I'm not trying to change the way git does things (which works perfectly
>>> well), I'm asking for some extra information to be added to the commit
>>> so that analysis of the ancestry graph can be tied to the branch topics
>>> that the original author was working from. [...]
> [...]
>> It is not just misleading but is actively wrong to recording the
>> name of the original branch in commits and carrying them forward via
>> rebase. If you want a record of what a group of commits were about,
>> the right time to do so is when you merge.
> [...]
> 
> There is even git-resurrect.sh script in 'contrib/' that makes
> use of that practice to find merged-in and deleted branches,
> and resurrect them (among other tools).
> 
> -- 
> Jakub Narębski
> 
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Feature request:

[Dany]

lol, confusion abound. this message was intended to be in response to "Re: Feature request: prevent push -f from pushing all branches at once"

On Jul 3, 2013, at 4:52 PM, Dany <nessup@gmail.com> wrote:

> Hey Jonathan,
> 
> Thanks for the quick reply. I think that's a great message; I do have to say that I wouldn't have known what the `matching` and `simple` modes are without that message; I just had to look it up is all. It may be helpful to tell users that `simple` is probably what they want :)
> 
> @DanyJoumaa
> 1 520 991 5001
> 
> On Jul 3, 2013, at 4:46 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> 
>> [I'm sorry about breaking Cc: chain - responding via GMane web interface]
>> 
>> Junio C Hamano <gitster <at> pobox.com> writes:
>>> Ed Hutchins <eh <at> demeterr.com> writes:
>>> 
>>>> I'm not trying to change the way git does things (which works perfectly
>>>> well), I'm asking for some extra information to be added to the commit
>>>> so that analysis of the ancestry graph can be tied to the branch topics
>>>> that the original author was working from. [...]
>> [...]
>>> It is not just misleading but is actively wrong to recording the
>>> name of the original branch in commits and carrying them forward via
>>> rebase. If you want a record of what a group of commits were about,
>>> the right time to do so is when you merge.
>> [...]
>> 
>> There is even git-resurrect.sh script in 'contrib/' that makes
>> use of that practice to find merged-in and deleted branches,
>> and resurrect them (among other tools).
>> 
>> -- 
>> Jakub Narębski
>> 
>> --
>> To unsubscribe from this list: send the line "unsubscribe git" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: Feature request:

[Matthieu Moy]

Dany <nessup@gmail.com> writes:

> lol, confusion abound. this message was intended to be in response to "Re: Feature request: prevent push -f from pushing all branches at once"

While we're there: please, don't top-post here. Quote the part of the
message you're replying to, and reply below.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: Feature request: "author branch" in commit object

[Philip Oakley]

From: "Junio C Hamano" <gitster@pobox.com>
Sent: Wednesday, July 03, 2013 7:08 PM
[catching up on old emails]
> Ed Hutchins <eh@demeterr.com> writes:
>
>> I'm not trying to change the way git does things (which works
>> perfectly
>> well), I'm asking for some extra information to be added to the
>> commit
>> so that analysis of the ancestry graph can be tied to the branch
>> topics
>> that the original author was working from. Currently if you have a
>> rebase-branch/ff-merge-to-master workflow, the graph of commits looks
>> like a single user produced all of the code. It would be very useful
>> for
>> both forensic and display purposes to categorize those commits by
>> their
>> original topics, but that history is lost in such a workflow.
>
> I am not following that "a single user" part. As long as these
> topics are done by different people, the authorship remains
> separate, no matter what the shape of the graph is.
>
> It all depends on what you show on the graph other than a circle and
> connecting lines, but I presume at least you would show the subject
> line. The graph would clearly show which groups of commits tackle
> what problems in your history, even if you excessively linearlized
> it by rebasing. You need subjects / commit log messages that are
> better than "bugfix", of course, for it to work, though.
>
>> Arguing that branch names are local and thus meaningless misses
>> the point: branches are *names* which were meaningful to the
>> author at the time the branch was being worked on.
>
> That is not necessarily true.
>
> Most of my commits start their life on a single branch that is named
> after a very broad theme (or even on a detached HEAD) that ends up
> touching different parts of the system and then later split into
> separate topic branches that are named after more detailed single
> issues. The name of the branch that happened to have been used to
> create them have almost no meaning after I am done with multiple and
> independent (but related in the larger scheme of things) topics.
>
> It is not just misleading but is actively wrong to recording the
> name of the original branch in commits and carrying them forward via
> rebase. If you want a record of what a group of commits were about,
> the right time to do so is when you merge.

While the general arguments are true that in the main one shouldn't
embed whatever random branch name was used into the commit messages,
there are some workflows and some production (corporate) environments
where adding a relevant branch name is suitable for that environment.

If the existing branch name is poor then the user should do a rebase to
transfer it to a better branch name, and then the 'git filter-branch'
command would be the obvious method to add a "Developed-on: <branch>"
final 'signoff line'.

The 'git filter-branch' man page already includes an example for adding
an acked by, which can easily be modified.

--
If you need to add Acked-by lines to, say, the last 10 commits (none of
which is a merge), use this command:

git filter-branch --msg-filter '
        cat &&
        echo "Acked-by: Bugs Bunny <bunny@bugzilla.org>"
' HEAD~10..HEAD
--

I'll leave it to Ed to automate it as a script.... (and possibly making 
sure it's idempotent so only the final branch name is retained, etc.)

>
> Projects that care about the shape of the ancestry graph have an
> obvious option of not excessively/unnecessarily linearlizing their
> history. We even have the "--no-ff" mode of merge to create an
> otherwise unnecessary merge to mark the point where a topic is
> merged to the mainline, so that merge log messages can say what
> topic was merged (and also you can even have "merge.log").
>
> Cleaning up a messy history created on a topic branch before
> presenting to others by lineralizing is one thing. It is a good
> practice. Requiring any update to fast-forward on top of the tip of
> the project is quite different. It does not make your history any
> easier to read. A topic that has been working fine on top of last
> week's trunk can have a subtle interaction with the work done by
> others on the trunk since it forked, and rebasing it on top of
> today's trunk, just before pushing it out on the trunk, risks
> breaking the topic in a subtle way without the person who does such
> a rebase without noticing, making later bisection harder.
>
> Any option to encourage such an artificially linear history _is_
> actively detrimental.
> --

Philip
The boss may not always be right, but she is the boss.