Re: Feature request: "author branch" in commit object
From: "Junio C Hamano" Sent: Wednesday, July 03, 2013 7:08 PM [catching up on old emails] Ed Hutchins 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: " 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 " ' 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Feature request: "author branch" in commit object
On 4 July 2013 09:46, Jakub Narebski wrote: > Junio C Hamano 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Feature request: "author branch" in commit object
Ed Hutchins 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Feature request: "author branch" in commit object
Ed Hutchins 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Feature request: "author branch" in commit object
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 wrote: > On Tue, Jul 2, 2013 at 10:34 PM, Ed Hutchins 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Feature request: "author branch" in commit object
On Tue, Jul 2, 2013 at 10:34 PM, Ed Hutchins 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Feature request: "author branch" in commit object
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 wrote: > Ed Hutchins 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/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Feature request: "author branch" in commit object
Ed Hutchins 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/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Feature request: "author branch" in commit object
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 wrote: > Ed Hutchins 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Feature request: "author branch" in commit object
On Tue, Jul 2, 2013 at 9:37 PM, 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? 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, www.herland.net -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Feature request: "author branch" in commit object
Ed Hutchins 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Feature request: "author branch" in commit object
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: iv...@iveqy.com -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Feature request: "author branch" in commit object
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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
