{"thread":{"id":"34327","subject":"Feature request: \"author branch\" in commit object","startedAt":"2013-07-02T19:37:13Z","lastAt":"2013-07-09T21:46:36Z","messageCount":17,"participants":["Ed Hutchins","Fredrik Gustafsson","Junio C Hamano","Johan Herland","Matthieu Moy","Antoine Pelisse","Jakub Narebski","Dany","Andrew Ardill","Philip Oakley"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"222395","messageId":"CADL+T9YGtvFrzStxJW64OJEV6H0BroMbkVCJdsDwWDaUWd91zQ@mail.gmail.com","threadId":"34327","inReplyTo":null,"subject":"Feature request: \"author branch\" in commit object","fromName":"Ed Hutchins","fromEmail":"eh@demeterr.com","sentAt":"2013-07-02T19:37:13Z","receivedAt":"2013-07-02T19:37:13Z","isPatch":false,"sender":{"key":"eh@demeterr.com","avatar":"https://gravatar.com/avatar/6512c62302127c95cb5f782b6feff76821ed1b2df895765bfbe37272c958ede1?d=mp&s=160"},"body":"I realize that branch names are ephemeral repo-specific things, but it\nwould be really useful to be able to determine what branch a commit\nwas authored from (as a hint to ancestry graph layout tools, for\nexample). Is there any way to do this currently, is it planned, or\nwould it be deemed useful enough to be worth adding to each commit\nobject?\n\n - Ed\n"},{"id":"222396","messageId":"20130702194909.GA24661@paksenarrion.iveqy.com","threadId":"34327","inReplyTo":"CADL+T9YGtvFrzStxJW64OJEV6H0BroMbkVCJdsDwWDaUWd91zQ@mail.gmail.com","subject":"Re: Feature request: \"author branch\" in commit object","fromName":"Fredrik Gustafsson","fromEmail":"iveqy@iveqy.com","sentAt":"2013-07-02T19:49:09Z","receivedAt":"2013-07-02T19:49:09Z","isPatch":false,"sender":{"key":"iveqy@iveqy.com","avatar":"https://avatars.githubusercontent.com/u/761743?v=4"},"body":"On Tue, Jul 02, 2013 at 12:37:13PM -0700, Ed Hutchins wrote:\n> I realize that branch names are ephemeral repo-specific things, but it\n> would be really useful to be able to determine what branch a commit\n> was authored from (as a hint to ancestry graph layout tools, for\n> example). Is there any way to do this currently, is it planned, or\n> would it be deemed useful enough to be worth adding to each commit\n> object?\n\nLet's see if I understand you. You want to (for each commit) to be able\nto tell the branch-name the commit had at the creation time?\n\nNot all commits have branches (however, loose commits is usually not\nwanted). Many commits are part of many branches.\n\nA branch is not a collection of commits but a pointer to a commit (which\nhas parents).\n\n-- \nMed vänliga hälsningar\nFredrik Gustafsson\n\ntel: 0733-608274\ne-post: iveqy@iveqy.com\n"},{"id":"222397","messageId":"7v38rwlola.fsf@alter.siamese.dyndns.org","threadId":"34327","inReplyTo":"CADL+T9YGtvFrzStxJW64OJEV6H0BroMbkVCJdsDwWDaUWd91zQ@mail.gmail.com","subject":"Re: Feature request: \"author branch\" in commit object","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-07-02T20:00:01Z","receivedAt":"2013-07-02T20:00:01Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ed Hutchins writes:\n\n> I realize that branch names are ephemeral repo-specific things, but it\n> would be really useful to be able to determine what branch a commit\n> was authored from (as a hint to ancestry graph layout tools, for\n> example).\n\nHmm. I think the current thinking so far is that it is harmful to\nengrave that information in the commit object, exactly for the\nreason you stated upfront: these names are local in the repository\nthe commit was created, and do not have any global meaning.\n\n> Is there any way to do this currently, is it planned, or\n> would it be deemed useful enough to be worth adding to each commit\n> object?\n\nNo, no, and no, not because it is not just useful enough but it may\nbe actively harmful.\n"},{"id":"222399","messageId":"CALKQrgf_Gv=+zUwcdDUPENj59kx1CbEwELnYZjArBZ1S8ueVcg@mail.gmail.com","threadId":"34327","inReplyTo":"CADL+T9YGtvFrzStxJW64OJEV6H0BroMbkVCJdsDwWDaUWd91zQ@mail.gmail.com","subject":"Re: Feature request: \"author branch\" in commit object","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2013-07-02T20:31:03Z","receivedAt":"2013-07-02T20:31:03Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Tue, Jul 2, 2013 at 9:37 PM, Ed Hutchins wrote:\n> I realize that branch names are ephemeral repo-specific things, but it\n> would be really useful to be able to determine what branch a commit\n> was authored from (as a hint to ancestry graph layout tools, for\n> example). Is there any way to do this currently, is it planned, or\n> would it be deemed useful enough to be worth adding to each commit\n> object?\n\nAs Junio stated elsewhere in the thread: No.\n\nHowever, you could do this with \"git notes\", which allows you to\nattach information to a commit object without changing the commit\nobject itself. Of course, for this to work, you would have to write a\npost-commit hook to record the branch information in a commit note,\nand then convince all contributors in your project to install the same\nhook. Then you'd need to teach the relevant graph layout tools to pay\nattention to your notes.\n\n...Johan\n\n-- \nJohan Herland, \nwww.herland.net\n"},{"id":"222400","messageId":"CADL+T9ax0maws3GR24YV77Yge7knqHd5mfuPd_AqE9b4UmvYPg@mail.gmail.com","threadId":"34327","inReplyTo":"7v38rwlola.fsf@alter.siamese.dyndns.org","subject":"Re: Feature request: \"author branch\" in commit object","fromName":"Ed Hutchins","fromEmail":"eh@demeterr.com","sentAt":"2013-07-02T20:34:05Z","receivedAt":"2013-07-02T20:34:05Z","isPatch":false,"sender":{"key":"eh@demeterr.com","avatar":"https://gravatar.com/avatar/6512c62302127c95cb5f782b6feff76821ed1b2df895765bfbe37272c958ede1?d=mp&s=160"},"body":"I'm not sure I follow how it could be actively harmful? I would think\nthe \"author branch\"\nnomenclature (as opposed to just calling it \"branch\") along with clear\ndocumentation\nthat these values are just captures of the particular state the commit\nwas authored\nfrom would more than assuage any potential misuse. On the other hand\ntrying to figure\nout the history of events from a large directed graph of commits\nwithout any clue about\nwhat topics first spawned each commit is actively harmful in many\ncases (trying to display\na clear history of who did what for what reasons, for example).\n\n\n\n\nOn Tue, Jul 2, 2013 at 1:00 PM, Junio C Hamano wrote:\n> Ed Hutchins writes:\n>\n>> I realize that branch names are ephemeral repo-specific things, but it\n>> would be really useful to be able to determine what branch a commit\n>> was authored from (as a hint to ancestry graph layout tools, for\n>> example).\n>\n> Hmm. I think the current thinking so far is that it is harmful to\n> engrave that information in the commit object, exactly for the\n> reason you stated upfront: these names are local in the repository\n> the commit was created, and do not have any global meaning.\n>\n>> Is there any way to do this currently, is it planned, or\n>> would it be deemed useful enough to be worth adding to each commit\n>> object?\n>\n> No, no, and no, not because it is not just useful enough but it may\n> be actively harmful.\n"},{"id":"222449","messageId":"vpqehbgrnrx.fsf@anie.imag.fr","threadId":"34327","inReplyTo":"CADL+T9YGtvFrzStxJW64OJEV6H0BroMbkVCJdsDwWDaUWd91zQ@mail.gmail.com","subject":"Re: Feature request: \"author branch\" in commit object","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-07-03T09:33:22Z","receivedAt":"2013-07-03T09:33:22Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Ed Hutchins writes:\n\n> I realize that branch names are ephemeral repo-specific things, but it\n> would be really useful to be able to determine what branch a commit\n> was authored from (as a hint to ancestry graph layout tools, for\n> example). Is there any way to do this currently, is it planned, or\n> would it be deemed useful enough to be worth adding to each commit\n> object?\n\nFWIW, this is what Mercurial's \"named branches\" do. Instead of having\nbranches point to commit, each commit says what branch it belongs to.\n\nOne drawback of this approach is that the branch name is part of the\ncommit and can't be changed without changing the commit's sha1. Hence, a\nlocal, private, branch name becomes permanent the day it's merged\nupstream.\n\n(for completeness: Mercurial also has essentially Git-like branches,\nbut they call this \"bookmarks\")\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"222467","messageId":"CADL+T9Z=SrVyMMnYk3M7Dmb4c5xGiQtCTiDYaceKwB2-51TV-g@mail.gmail.com","threadId":"34327","inReplyTo":"vpqehbgrnrx.fsf@anie.imag.fr","subject":"Re: Feature request: \"author branch\" in commit object","fromName":"Ed Hutchins","fromEmail":"eh@demeterr.com","sentAt":"2013-07-03T15:47:17Z","receivedAt":"2013-07-03T15:47:17Z","isPatch":false,"sender":{"key":"eh@demeterr.com","avatar":"https://gravatar.com/avatar/6512c62302127c95cb5f782b6feff76821ed1b2df895765bfbe37272c958ede1?d=mp&s=160"},"body":"I'm not trying to change the way git does things (which works perfectly\nwell), I'm asking for some extra information to be added to the commit\nso that analysis of the ancestry graph can be tied to the branch topics\nthat the original author was working from. Currently if you have a\nrebase-branch/ff-merge-to-master workflow, the graph of commits looks\nlike a single user produced all of the code. It would be very useful for\nboth forensic and display purposes to categorize those commits by their\noriginal topics, but that history is lost in such a workflow. Certainly\nthere are work-arounds (notes etc.) to capture this history, but I think\nthat this is a basic feature which most projects would benefit from. I\nfully understand that branches are not global and that it may be\nconfusing to keep an \"author branch\" name around in some cases, but the\nvast majority of cases where authors pick meaningful branch names would\nbenefit from being able to look back and go \"ah-ha! that was a commit to\nfix bug such-and-such\" or \"that was a commit from when I was working on\nsuper-cool feature X\". Even just knowing that two commits were from\ndifferent (or the same) branches would tell you something useful about\nthe evolution of the project. Arguing that branch names are local and\nthus meaningless misses the point: branches are *names* which were\nmeaningful to the author at the time the branch was being worked on.\nDiscarding this information makes it harder to reason about or display\nthe history of the project and is an irritating defect in an otherwise\nwonderful tool.\n\nOn Wed, Jul 3, 2013 at 2:33 AM, Matthieu Moy\n wrote:\n> Ed Hutchins writes:\n>\n>> I realize that branch names are ephemeral repo-specific things, but it\n>> would be really useful to be able to determine what branch a commit\n>> was authored from (as a hint to ancestry graph layout tools, for\n>> example). Is there any way to do this currently, is it planned, or\n>> would it be deemed useful enough to be worth adding to each commit\n>> object?\n>\n> FWIW, this is what Mercurial's \"named branches\" do. Instead of having\n> branches point to commit, each commit says what branch it belongs to.\n>\n> One drawback of this approach is that the branch name is part of the\n> commit and can't be changed without changing the commit's sha1. Hence, a\n> local, private, branch name becomes permanent the day it's merged\n> upstream.\n>\n> (for completeness: Mercurial also has essentially Git-like branches,\n> but they call this \"bookmarks\")\n>\n> --\n> Matthieu Moy\n> http://www-verimag.imag.fr/~moy/\n"},{"id":"222468","messageId":"CALWbr2zJFjbaCdA3d1eaFuP4HGShAwnK=gisRD=KHKWWi-XuTg@mail.gmail.com","threadId":"34327","inReplyTo":"CADL+T9ax0maws3GR24YV77Yge7knqHd5mfuPd_AqE9b4UmvYPg@mail.gmail.com","subject":"Re: Feature request: \"author branch\" in commit object","fromName":"Antoine Pelisse","fromEmail":"apelisse@gmail.com","sentAt":"2013-07-03T16:16:41Z","receivedAt":"2013-07-03T16:16:41Z","isPatch":false,"sender":{"key":"apelisse@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1929644?v=4"},"body":"On Tue, Jul 2, 2013 at 10:34 PM, Ed Hutchins wrote:\n> On the other hand\n> trying to figure\n> out the history of events from a large directed graph of commits\n> without any clue about\n> what topics first spawned each commit is actively harmful in many\n> cases (trying to display\n> a clear history of who did what for what reasons, for example).\n\nI think this is exactly what Junio does with git.git:\n- Each branch is named \"$initials/$topicname\" before being merged.\n- Branches are always merged with --no-ff.\n\nI think it answers your question: Who (initials) does what (topic)\nThe name of the branch is also stuck as part of the history as the\nmerge reads the name of the merged branch:\n\ne.g. Merge branch 'rr/remote-branch-config-refresh'\n\nYou can of course provide more information than the simple commit\nheader line (that would give the \"what reasons\").\n\nOf course, it's even easier to read if you always merge in the same\ndirection (that allows you to easily find the first commit of the\nbranch).\n\nHope that helps,\nAntoine\n"},{"id":"222472","messageId":"CADL+T9bbnGSxCjUBqoL3qm7Ss-j9jxorED0L1A6v1NbeLBpRQg@mail.gmail.com","threadId":"34327","inReplyTo":"CALWbr2zJFjbaCdA3d1eaFuP4HGShAwnK=gisRD=KHKWWi-XuTg@mail.gmail.com","subject":"Re: Feature request: \"author branch\" in commit object","fromName":"Ed Hutchins","fromEmail":"eh@demeterr.com","sentAt":"2013-07-03T17:31:51Z","receivedAt":"2013-07-03T17:31:51Z","isPatch":false,"sender":{"key":"eh@demeterr.com","avatar":"https://gravatar.com/avatar/6512c62302127c95cb5f782b6feff76821ed1b2df895765bfbe37272c958ede1?d=mp&s=160"},"body":"I might be able to switch our corporate workflow to adding non-ff merge\ncommits, but the reason we moved away from using github's big red button\nin the first place was to avoid the extra noise of merge-only commits.\n\nActually you've pointed out an inconsistency: why is it okay for merge\ncommits to automatically mention branch names, but for regular commits\nthis is considered harmful?\n\nOn Wed, Jul 3, 2013 at 9:16 AM, Antoine Pelisse wrote:\n> On Tue, Jul 2, 2013 at 10:34 PM, Ed Hutchins wrote:\n>> On the other hand\n>> trying to figure\n>> out the history of events from a large directed graph of commits\n>> without any clue about\n>> what topics first spawned each commit is actively harmful in many\n>> cases (trying to display\n>> a clear history of who did what for what reasons, for example).\n>\n> I think this is exactly what Junio does with git.git:\n> - Each branch is named \"$initials/$topicname\" before being merged.\n> - Branches are always merged with --no-ff.\n>\n> I think it answers your question: Who (initials) does what (topic)\n> The name of the branch is also stuck as part of the history as the\n> merge reads the name of the merged branch:\n>\n> e.g. Merge branch 'rr/remote-branch-config-refresh'\n>\n> You can of course provide more information than the simple commit\n> header line (that would give the \"what reasons\").\n>\n> Of course, it's even easier to read if you always merge in the same\n> direction (that allows you to easily find the first commit of the\n> branch).\n>\n> Hope that helps,\n> Antoine\n"},{"id":"222474","messageId":"7vppuzfrde.fsf@alter.siamese.dyndns.org","threadId":"34327","inReplyTo":"CADL+T9Z=SrVyMMnYk3M7Dmb4c5xGiQtCTiDYaceKwB2-51TV-g@mail.gmail.com","subject":"Re: Feature request: \"author branch\" in commit object","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-07-03T18:08:45Z","receivedAt":"2013-07-03T18:08:45Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ed Hutchins writes:\n\n> I'm not trying to change the way git does things (which works perfectly\n> well), I'm asking for some extra information to be added to the commit\n> so that analysis of the ancestry graph can be tied to the branch topics\n> that the original author was working from. Currently if you have a\n> rebase-branch/ff-merge-to-master workflow, the graph of commits looks\n> like a single user produced all of the code. It would be very useful for\n> both forensic and display purposes to categorize those commits by their\n> original topics, but that history is lost in such a workflow.\n\nI am not following that \"a single user\" part. As long as these\ntopics are done by different people, the authorship remains\nseparate, no matter what the shape of the graph is.\n\nIt all depends on what you show on the graph other than a circle and\nconnecting lines, but I presume at least you would show the subject\nline. The graph would clearly show which groups of commits tackle\nwhat problems in your history, even if you excessively linearlized\nit by rebasing. You need subjects / commit log messages that are\nbetter than \"bugfix\", of course, for it to work, though.\n\n> Arguing that branch names are local and thus meaningless misses\n> the point: branches are *names* which were meaningful to the\n> author at the time the branch was being worked on.\n\nThat is not necessarily true.\n\nMost of my commits start their life on a single branch that is named\nafter a very broad theme (or even on a detached HEAD) that ends up\ntouching different parts of the system and then later split into\nseparate topic branches that are named after more detailed single\nissues. The name of the branch that happened to have been used to\ncreate them have almost no meaning after I am done with multiple and\nindependent (but related in the larger scheme of things) topics.\n\nIt is not just misleading but is actively wrong to recording the\nname of the original branch in commits and carrying them forward via\nrebase. If you want a record of what a group of commits were about,\nthe right time to do so is when you merge.\n\nProjects that care about the shape of the ancestry graph have an\nobvious option of not excessively/unnecessarily linearlizing their\nhistory. We even have the \"--no-ff\" mode of merge to create an\notherwise unnecessary merge to mark the point where a topic is\nmerged to the mainline, so that merge log messages can say what\ntopic was merged (and also you can even have \"merge.log\").\n\nCleaning up a messy history created on a topic branch before\npresenting to others by lineralizing is one thing. It is a good\npractice. Requiring any update to fast-forward on top of the tip of\nthe project is quite different. It does not make your history any\neasier to read. A topic that has been working fine on top of last\nweek's trunk can have a subtle interaction with the work done by\nothers on the trunk since it forked, and rebasing it on top of\ntoday's trunk, just before pushing it out on the trunk, risks\nbreaking the topic in a subtle way without the person who does such\na rebase without noticing, making later bisection harder.\n\nAny option to encourage such an artificially linear history _is_\nactively detrimental.\n"},{"id":"222476","messageId":"7vli5nfquq.fsf@alter.siamese.dyndns.org","threadId":"34327","inReplyTo":"CADL+T9bbnGSxCjUBqoL3qm7Ss-j9jxorED0L1A6v1NbeLBpRQg@mail.gmail.com","subject":"Re: Feature request: \"author branch\" in commit object","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-07-03T18:19:57Z","receivedAt":"2013-07-03T18:19:57Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ed Hutchins writes:\n\n> I might be able to switch our corporate workflow to adding non-ff merge\n> commits, but the reason we moved away from using github's big red button\n> in the first place was to avoid the extra noise of merge-only commits.\n>\n> Actually you've pointed out an inconsistency: why is it okay for merge\n> commits to automatically mention branch names, but for regular commits\n> this is considered harmful?\n\nWe do not care what you write as part of human-readable payload.\n\nYour local convention could be to add, near the end of your log\nmessages, \"Made-on-branch: frotz\" line, just like all the commits in\nour project have \"Signed-off-by: line\" at the end.\n\nThe problem we avoid is to add it as structural part of the commit\nobject.\n"},{"id":"222520","messageId":"loom.20130704T013747-723@post.gmane.org","threadId":"34327","inReplyTo":"7vppuzfrde.fsf@alter.siamese.dyndns.org","subject":"Re: Feature request:","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2013-07-03T23:46:19Z","receivedAt":"2013-07-03T23:46:19Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"[I'm sorry about breaking Cc: chain - responding via GMane web interface]\n\nJunio C Hamano pobox.com> writes:\n> Ed Hutchins demeterr.com> writes:\n> \n> > I'm not trying to change the way git does things (which works perfectly\n> > well), I'm asking for some extra information to be added to the commit\n> > so that analysis of the ancestry graph can be tied to the branch topics\n> > that the original author was working from. [...]\n[...]\n> It is not just misleading but is actively wrong to recording the\n> name of the original branch in commits and carrying them forward via\n> rebase. If you want a record of what a group of commits were about,\n> the right time to do so is when you merge.\n[...]\n\nThere is even git-resurrect.sh script in 'contrib/' that makes\nuse of that practice to find merged-in and deleted branches,\nand resurrect them (among other tools).\n\n-- \nJakub Narębski\n"},{"id":"222521","messageId":"67824DCD-A486-476D-9A04-D18B083DB090@gmail.com","threadId":"34327","inReplyTo":"loom.20130704T013747-723@post.gmane.org","subject":"Re: Feature request:","fromName":"Dany","fromEmail":"nessup@gmail.com","sentAt":"2013-07-03T23:52:16Z","receivedAt":"2013-07-03T23:52:16Z","isPatch":false,"sender":{"key":"nessup@gmail.com","avatar":null},"body":"Hey Jonathan,\n\nThanks 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 :)\n\n@DanyJoumaa\n1 520 991 5001\n\nOn Jul 3, 2013, at 4:46 PM, Jakub Narebski wrote:\n\n> [I'm sorry about breaking Cc: chain - responding via GMane web interface]\n> \n> Junio C Hamano pobox.com> writes:\n>> Ed Hutchins demeterr.com> writes:\n>> \n>>> I'm not trying to change the way git does things (which works perfectly\n>>> well), I'm asking for some extra information to be added to the commit\n>>> so that analysis of the ancestry graph can be tied to the branch topics\n>>> that the original author was working from. [...]\n> [...]\n>> It is not just misleading but is actively wrong to recording the\n>> name of the original branch in commits and carrying them forward via\n>> rebase. If you want a record of what a group of commits were about,\n>> the right time to do so is when you merge.\n> [...]\n> \n> There is even git-resurrect.sh script in 'contrib/' that makes\n> use of that practice to find merged-in and deleted branches,\n> and resurrect them (among other tools).\n> \n> -- \n> Jakub Narębski\n> \n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n"},{"id":"222522","messageId":"686269E5-8539-42F9-B0B6-D7CA996A4FF2@gmail.com","threadId":"34327","inReplyTo":"67824DCD-A486-476D-9A04-D18B083DB090@gmail.com","subject":"Re: Feature request:","fromName":"Dany","fromEmail":"nessup@gmail.com","sentAt":"2013-07-03T23:53:18Z","receivedAt":"2013-07-03T23:53:18Z","isPatch":false,"sender":{"key":"nessup@gmail.com","avatar":null},"body":"lol, confusion abound. this message was intended to be in response to \"Re: Feature request: prevent push -f from pushing all branches at once\"\n\nOn Jul 3, 2013, at 4:52 PM, Dany wrote:\n\n> Hey Jonathan,\n> \n> 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 :)\n> \n> @DanyJoumaa\n> 1 520 991 5001\n> \n> On Jul 3, 2013, at 4:46 PM, Jakub Narebski wrote:\n> \n>> [I'm sorry about breaking Cc: chain - responding via GMane web interface]\n>> \n>> Junio C Hamano pobox.com> writes:\n>>> Ed Hutchins demeterr.com> writes:\n>>> \n>>>> I'm not trying to change the way git does things (which works perfectly\n>>>> well), I'm asking for some extra information to be added to the commit\n>>>> so that analysis of the ancestry graph can be tied to the branch topics\n>>>> that the original author was working from. [...]\n>> [...]\n>>> It is not just misleading but is actively wrong to recording the\n>>> name of the original branch in commits and carrying them forward via\n>>> rebase. If you want a record of what a group of commits were about,\n>>> the right time to do so is when you merge.\n>> [...]\n>> \n>> There is even git-resurrect.sh script in 'contrib/' that makes\n>> use of that practice to find merged-in and deleted branches,\n>> and resurrect them (among other tools).\n>> \n>> -- \n>> Jakub Narębski\n>> \n>> --\n>> To unsubscribe from this list: send the line \"unsubscribe git\" in\n>> the body of a message to majordomo@vger.kernel.org\n>> More majordomo info at http://vger.kernel.org/majordomo-info.html\n> \n"},{"id":"222523","messageId":"CAH5451kq-zmy1kFFqx44ba4iM+H4zCF2J3GMc2ppcmoz5=urXA@mail.gmail.com","threadId":"34327","inReplyTo":"7vli5nfquq.fsf@alter.siamese.dyndns.org","subject":"Re: Feature request: \"author branch\" in commit object","fromName":"Andrew Ardill","fromEmail":"andrew.ardill@gmail.com","sentAt":"2013-07-04T00:00:48Z","receivedAt":"2013-07-04T00:00:48Z","isPatch":false,"sender":{"key":"andrew.ardill@gmail.com","avatar":"https://gravatar.com/avatar/da14cb7c091dd44dc6c63a4d3361b149acaf25226dc78eb4131a17b93d9b0993?d=mp&s=160"},"body":"On 4 July 2013 09:46, Jakub Narebski wrote:\n> Junio C Hamano pobox.com> writes:\n>> It is not just misleading but is actively wrong to recording the\n>> name of the original branch in commits and carrying them forward via\n>> rebase. If you want a record of what a group of commits were about,\n>> the right time to do so is when you merge.\n>\n> There is even git-resurrect.sh script in 'contrib/' that makes\n> use of that practice to find merged-in and deleted branches,\n> and resurrect them (among other tools).\n\nHow do users who wish to keep a record of branch names find out that\n--no-ff will enable this behaviour?\n\nIs this a common enough requirement to make --no-ff the default\nbehaviour (probably not, and that transition would be painful)?\n\nWhat are the shortcomings of using --no-ff in the analogue to how\nmercurials named branches work?\n\nI think the git-flow and git-list style workflows have done a lot to\npromote a set of usage patterns that keep this metadata around, I just\nwonder if we can do more to assist users in what seems to be a\nrelatively common request.\n\nRegards,\n\nAndrew Ardill\n"},{"id":"222531","messageId":"vpq1u7e7nnp.fsf@anie.imag.fr","threadId":"34327","inReplyTo":"686269E5-8539-42F9-B0B6-D7CA996A4FF2@gmail.com","subject":"Re: Feature request:","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-07-04T08:08:26Z","receivedAt":"2013-07-04T08:08:26Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Dany writes:\n\n> lol, confusion abound. this message was intended to be in response to \"Re: Feature request: prevent push -f from pushing all branches at once\"\n\nWhile we're there: please, don't top-post here. Quote the part of the\nmessage you're replying to, and reply below.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"222977","messageId":"E66A4CB66EF64CE5A46851045BFB48FA@PhilipOakley","threadId":"34327","inReplyTo":"7vppuzfrde.fsf@alter.siamese.dyndns.org","subject":"Re: Feature request: \"author branch\" in commit object","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2013-07-09T21:46:36Z","receivedAt":"2013-07-09T21:46:36Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Junio C Hamano\" \nSent: Wednesday, July 03, 2013 7:08 PM\n[catching up on old emails]\n> Ed Hutchins writes:\n>\n>> I'm not trying to change the way git does things (which works\n>> perfectly\n>> well), I'm asking for some extra information to be added to the\n>> commit\n>> so that analysis of the ancestry graph can be tied to the branch\n>> topics\n>> that the original author was working from. Currently if you have a\n>> rebase-branch/ff-merge-to-master workflow, the graph of commits looks\n>> like a single user produced all of the code. It would be very useful\n>> for\n>> both forensic and display purposes to categorize those commits by\n>> their\n>> original topics, but that history is lost in such a workflow.\n>\n> I am not following that \"a single user\" part. As long as these\n> topics are done by different people, the authorship remains\n> separate, no matter what the shape of the graph is.\n>\n> It all depends on what you show on the graph other than a circle and\n> connecting lines, but I presume at least you would show the subject\n> line. The graph would clearly show which groups of commits tackle\n> what problems in your history, even if you excessively linearlized\n> it by rebasing. You need subjects / commit log messages that are\n> better than \"bugfix\", of course, for it to work, though.\n>\n>> Arguing that branch names are local and thus meaningless misses\n>> the point: branches are *names* which were meaningful to the\n>> author at the time the branch was being worked on.\n>\n> That is not necessarily true.\n>\n> Most of my commits start their life on a single branch that is named\n> after a very broad theme (or even on a detached HEAD) that ends up\n> touching different parts of the system and then later split into\n> separate topic branches that are named after more detailed single\n> issues. The name of the branch that happened to have been used to\n> create them have almost no meaning after I am done with multiple and\n> independent (but related in the larger scheme of things) topics.\n>\n> It is not just misleading but is actively wrong to recording the\n> name of the original branch in commits and carrying them forward via\n> rebase. If you want a record of what a group of commits were about,\n> the right time to do so is when you merge.\n\nWhile the general arguments are true that in the main one shouldn't\nembed whatever random branch name was used into the commit messages,\nthere are some workflows and some production (corporate) environments\nwhere adding a relevant branch name is suitable for that environment.\n\nIf the existing branch name is poor then the user should do a rebase to\ntransfer it to a better branch name, and then the 'git filter-branch'\ncommand would be the obvious method to add a \"Developed-on: \"\nfinal 'signoff line'.\n\nThe 'git filter-branch' man page already includes an example for adding\nan acked by, which can easily be modified.\n\n--\nIf you need to add Acked-by lines to, say, the last 10 commits (none of\nwhich is a merge), use this command:\n\ngit filter-branch --msg-filter '\n cat &&\n echo \"Acked-by: Bugs Bunny \"\n' HEAD~10..HEAD\n--\n\nI'll leave it to Ed to automate it as a script.... (and possibly making \nsure it's idempotent so only the final branch name is retained, etc.)\n\n>\n> Projects that care about the shape of the ancestry graph have an\n> obvious option of not excessively/unnecessarily linearlizing their\n> history. We even have the \"--no-ff\" mode of merge to create an\n> otherwise unnecessary merge to mark the point where a topic is\n> merged to the mainline, so that merge log messages can say what\n> topic was merged (and also you can even have \"merge.log\").\n>\n> Cleaning up a messy history created on a topic branch before\n> presenting to others by lineralizing is one thing. It is a good\n> practice. Requiring any update to fast-forward on top of the tip of\n> the project is quite different. It does not make your history any\n> easier to read. A topic that has been working fine on top of last\n> week's trunk can have a subtle interaction with the work done by\n> others on the trunk since it forked, and rebasing it on top of\n> today's trunk, just before pushing it out on the trunk, risks\n> breaking the topic in a subtle way without the person who does such\n> a rebase without noticing, making later bisection harder.\n>\n> Any option to encourage such an artificially linear history _is_\n> actively detrimental.\n> --\n\nPhilip\nThe boss may not always be right, but she is the boss. \n"}]}