{"thread":{"id":"36508","subject":"Recording the current branch on each commit?","startedAt":"2014-04-26T23:56:47Z","lastAt":"2014-04-30T01:11:05Z","messageCount":69,"participants":["Jeremy Morton","Robin Rosenberg","Johan Herland","James Denholm","Sitaram Chamarty","David Kastrup","Christian Couder","Felipe Contreras","Junio C Hamano","Piotr Krukowiecki","David Lang"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"239785","messageId":"535C47BF.2070805@game-point.net","threadId":"36508","inReplyTo":null,"subject":"Recording the current branch on each commit?","fromName":"Jeremy Morton","fromEmail":"admin@game-point.net","sentAt":"2014-04-26T23:56:47Z","receivedAt":"2014-04-26T23:56:47Z","isPatch":false,"sender":{"key":"admin@game-point.net","avatar":null},"body":"Currently, git records a checksum, author, commit date/time, and commit \nmessage with every commit (as get be seen from 'git log'). I think it \nwould be useful if, along with the Author and Date, git recorded the \nname of the current branch on each commit. The branch name can provide \nuseful contextual information. For instance, let's say I'm developing a \nsuite of games. If the commit message says \"Added basic options \ndialog\", it might be useful to see that the branch name is \n\"pacman-minigame\" indicating that the commit pertains to the options \ndialog in the Pacman minigame. Basically, I'm saying that well-named \nbranches can and do carry useful contextual information that oughtn't to \nbe thrown away. Currently, when you delete that branch, you lose the \nbranch name altogether.\n\nSo what do you think? Would it be good to have a patch to add this feature?\n\n-- \nBest regards,\nJeremy Morton (Jez)\n"},{"id":"239792","messageId":"1748955386.11457068.1398588660139.JavaMail.zimbra@dewire.com","threadId":"36508","inReplyTo":"535C47BF.2070805@game-point.net","subject":"Re: Recording the current branch on each commit?","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg@dewire.com","sentAt":"2014-04-27T08:51:00Z","receivedAt":"2014-04-27T08:51:00Z","isPatch":false,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"\n\n----- Ursprungligt meddelande -----\n> Från: \"Jeremy Morton\" \n> Till: git@vger.kernel.org\n> Skickat: söndag, 27 apr 2014 1:56:47\n> Ämne: Recording the current branch on each commit?\n> \n> Currently, git records a checksum, author, commit date/time, and commit\n> message with every commit (as get be seen from 'git log'). I think it\n> would be useful if, along with the Author and Date, git recorded the\n> name of the current branch on each commit. The branch name can provide\n> useful contextual information. For instance, let's say I'm developing a\n> suite of games. If the commit message says \"Added basic options\n> dialog\", it might be useful to see that the branch name is\n> \"pacman-minigame\" indicating that the commit pertains to the options\n> dialog in the Pacman minigame. Basically, I'm saying that well-named\n> branches can and do carry useful contextual information that oughtn't to\n> be thrown away. Currently, when you delete that branch, you lose the\n> branch name altogether.\n> \n> So what do you think? Would it be good to have a patch to add this feature?\n\nBranch names are usually poorly named, so often you don't lose much. One way\nsome people to is to always merge with --no-ff, that way you see the branch\nname in the merge commit. \n\nA very popular way of tracking context is to add some id, such as a bugzilla issue\nnumber, to the header or footer of the commit message. Often a branch contains many\nissues, but the branch itself isn't very interesting. Tools like gitblit, gitweb,\ngerrit etc can easily be configured to link to the issue using a regular expression.\n\n-- robin\n"},{"id":"239793","messageId":"CALKQrgfmBByMwMhxu3HkJqJGWy2Rwvij6Hi1_4npjfsxcSgpaQ@mail.gmail.com","threadId":"36508","inReplyTo":"535C47BF.2070805@game-point.net","subject":"Re: Recording the current branch on each commit?","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2014-04-27T09:09:28Z","receivedAt":"2014-04-27T09:09:28Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Sun, Apr 27, 2014 at 1:56 AM, Jeremy Morton wrote:\n> Currently, git records a checksum, author, commit date/time, and commit\n> message with every commit (as get be seen from 'git log'). I think it would\n> be useful if, along with the Author and Date, git recorded the name of the\n> current branch on each commit.\n\nThis has been discussed multiple times in the past. One example here:\nhttp://thread.gmane.org/gmane.comp.version-control.git/229422\n\nI believe the current conclusion (if any) is that encoding such\ninformation as a _structural_ part of the commit object is not useful.\nSee the old thread(s) for the actual pro/con arguments.\n\nThat said, you are of course free to add this information to your own\ncommit messages, by appending something like \"Made-on-branch: frotz\".\nIn a company setting, you can even create a commit message template or\n(prepare-)commit-msg hook to have this line created automatically for\nyou and your co-workers. You could even append such information\nretroactively to existing commits with \"git notes\". There is also the\ncurrent interpret-trailers effort by Christian Couder [1] that should\nbe useful in creating and managing such lines.\n\n[1]: http://thread.gmane.org/gmane.comp.version-control.git/245874\n\n> The branch name can provide useful\n> contextual information. For instance, let's say I'm developing a suite of\n> games. If the commit message says \"Added basic options dialog\", it might be\n> useful to see that the branch name is \"pacman-minigame\" indicating that the\n> commit pertains to the options dialog in the Pacman minigame.\n\nIn that partcular case, ISTM that the context (\"pacman-minigame\")\nwould actually be better preserved elsewhere. E.g. the commits touch\nfiles in a particular \"minigames/pacman\" subdir, or you prefix the\ncontext in the commit message (\"pacman-minigame: Added basic options\ndialog\"). Also, such a \"topic\" branch is often tied to a specific\nissue in some bug/issue tracker, and it would in any case be natural\nto mention the bug/issue ID in the commit message, at which point the\ntracker can provide more context and discussion.\n\n> Basically,\n> I'm saying that well-named branches can and do carry useful contextual\n> information that oughtn't to be thrown away. Currently, when you delete\n> that branch, you lose the branch name altogether.\n\nSome would argue that branches are not always well-named... But\nanyway, if the branch ends up getting merged to the mainline, the\nmerge commit defaults to a message like \"Merge branch\n'pacman-minigame'\".\n\n> So what do you think? Would it be good to have a patch to add this feature?\n\nOne is free to try, of course, but I wouldn't get my hopes up for a\npatch that changes the fundamental format of the commit object to\ninclude something that many users/workflows would consider to be pure\ncruft.\n\nIf you still believe that this is useful enough to warrant a change to\nthe commit object format, it is probably better to start off putting\nthe information in the commit message (as described above), and\nprovide some tools that demonstrate the added value of this\ninformation. If that is successful and gains momentum, the git\ncommunity can certainly reconsider whether it makes sense to fold it\ninto a more formalized part of the commit object.\n\n...Johan\n\n-- \nJohan Herland, \nwww.herland.net\n"},{"id":"239804","messageId":"535D3DF8.4020904@game-point.net","threadId":"36508","inReplyTo":"1748955386.11457068.1398588660139.JavaMail.zimbra@dewire.com","subject":"Re: Recording the current branch on each commit?","fromName":"Jeremy Morton","fromEmail":"admin@game-point.net","sentAt":"2014-04-27T17:27:20Z","receivedAt":"2014-04-27T17:27:20Z","isPatch":false,"sender":{"key":"admin@game-point.net","avatar":null},"body":"On 27/04/2014 09:51, Robin Rosenberg wrote:\n>> Currently, git records a checksum, author, commit date/time, and commit\n>> message with every commit (as get be seen from 'git log'). I think it\n>> would be useful if, along with the Author and Date, git recorded the\n>> name of the current branch on each commit. The branch name can provide\n>> useful contextual information. For instance, let's say I'm developing a\n>> suite of games. If the commit message says \"Added basic options\n>> dialog\", it might be useful to see that the branch name is\n>> \"pacman-minigame\" indicating that the commit pertains to the options\n>> dialog in the Pacman minigame. Basically, I'm saying that well-named\n>> branches can and do carry useful contextual information that oughtn't to\n>> be thrown away. Currently, when you delete that branch, you lose the\n>> branch name altogether.\n>>\n>> So what do you think? Would it be good to have a patch to add this feature?\n>\n> Branch names are usually poorly named, so often you don't lose much. One way\n\nSpeak for yourself - I give my branches useful names. :-) I definitely \nfeel that I am often losing useful contextual information by throwing \naway the branch name.\n\n> some people to is to always merge with --no-ff, that way you see the branch\n> name in the merge commit.\n\nBut surely, it's recommended with Git that you try to avoid doing \n--no-ff merges to avoid commit noise? Also, it is a lot more hassle \n(and no doubt, CPU cycles) to track down where a branch was merged to \ntry and figure out which branch name a commit pertained to, not to \nmention the fact that the commit could've been moved since. Nothing \nshort of tagging the commit with the branch name when the commit is made \nwill definitely record the branch name at the time of committing.\n\n> A very popular way of tracking context is to add some id, such as a bugzilla issue\n> number, to the header or footer of the commit message. Often a branch contains many\n> issues, but the branch itself isn't very interesting. Tools like gitblit, gitweb,\n> gerrit etc can easily be configured to link to the issue using a regular expression.\n\nYes, and I have done this kind of thing in the past. However you really \ndon't want to put the bug# on every single commit pertaining to that \nbug; you have to go to the effort of looking the bug# up every time, \nyou'll sometimes forget, and besides it takes up space that could be \nused for a commit message. As short commit messages are valued in Git, \nit's particularly bad to waste space this way. Much better would be to \ninclude the bug# as part of the branch name, and then if you record the \nbranch name upon checkin you always get a reference to the bug#.\n\nAlso, you don't always have something you can link a commit to in an \nissue tracker. You may just be implementing a feature that has been \nagreed upon, independently of any such tracker. In that case, there's \nno bug# to link to.\n\n-- \nBest regards,\nJeremy Morton (Jez)\n"},{"id":"239805","messageId":"535D4085.4040707@game-point.net","threadId":"36508","inReplyTo":"CALKQrgfmBByMwMhxu3HkJqJGWy2Rwvij6Hi1_4npjfsxcSgpaQ@mail.gmail.com","subject":"Re: Recording the current branch on each commit?","fromName":"Jeremy Morton","fromEmail":"admin@game-point.net","sentAt":"2014-04-27T17:38:13Z","receivedAt":"2014-04-27T17:38:13Z","isPatch":false,"sender":{"key":"admin@game-point.net","avatar":null},"body":"On 27/04/2014 10:09, Johan Herland wrote:\n> On Sun, Apr 27, 2014 at 1:56 AM, Jeremy Morton wrote:\n>> Currently, git records a checksum, author, commit date/time, and commit\n>> message with every commit (as get be seen from 'git log'). I think it would\n>> be useful if, along with the Author and Date, git recorded the name of the\n>> current branch on each commit.\n>\n> This has been discussed multiple times in the past. One example here:\n> http://thread.gmane.org/gmane.comp.version-control.git/229422\n>\n> I believe the current conclusion (if any) is that encoding such\n> information as a _structural_ part of the commit object is not useful.\n> See the old thread(s) for the actual pro/con arguments.\n\nAs far as I can tell from that discussion, the general opposition to \nencoding the branch name as a structural part of the commit object is \nthat, for some people's workflows, it would be unhelpful and/or \nmisleading. Well fair enough then - why don't we make it a setting that \nis off by default, and can easily be switched on? That way the people \nfor whom tagging the branch name would be useful have a very easy way to \nswitch it on. I know that for the workflows I personally have used in \nthe past, such tagging would be very useful. Quite often I have been \nlooking through the Git log and wondered what feature a commit was \"part \nof\", because I have feature branches. Just knowing that branch name \nwould be really useful, but the branch has since been deleted... and in \nthe case of a ff-merge (which I thought was recommended in Git if \npossible), the branch name is completely gone.\n\n> That said, you are of course free to add this information to your own\n> commit messages, by appending something like \"Made-on-branch: frotz\".\n> In a company setting, you can even create a commit message template or\n> (prepare-)commit-msg hook to have this line created automatically for\n> you and your co-workers. You could even append such information\n> retroactively to existing commits with \"git notes\". There is also the\n> current interpret-trailers effort by Christian Couder [1] that should\n> be useful in creating and managing such lines.\n>\n> [1]: http://thread.gmane.org/gmane.comp.version-control.git/245874\n\nWell I guess that's another way of doing it. So, why aren't Author and \nDate trailers? They don't seem any more fundamental to me than branch \nname. I mean the only checkin information you really *need* is the \nchecksum, and commit's parents. The Author and Date are just extra \npieces of information you might find useful sometimes, right? A bit \nlike some people might find branch checkin name useful sometimes...?\n\n>> The branch name can provide useful\n>> contextual information. For instance, let's say I'm developing a suite of\n>> games. If the commit message says \"Added basic options dialog\", it might be\n>> useful to see that the branch name is \"pacman-minigame\" indicating that the\n>> commit pertains to the options dialog in the Pacman minigame.\n>\n> In that partcular case, ISTM that the context (\"pacman-minigame\")\n> would actually be better preserved elsewhere. E.g. the commits touch\n> files in a particular \"minigames/pacman\" subdir, or you prefix the\n> context in the commit message (\"pacman-minigame: Added basic options\n> dialog\"). Also, such a \"topic\" branch is often tied to a specific\n\nAgain, this is a pain because you have to remember to manually tag every \ncommit message with \"pacman-minigame\", and it takes up precious space in \nthe (already short) commit message.\n\n> issue in some bug/issue tracker, and it would in any case be natural\n> to mention the bug/issue ID in the commit message, at which point the\n> tracker can provide more context and discussion.\n\nI think it would only be natural to mention the bug# in the final commit \nthat actually fixes the bug or implements the feature, not the checkins \nleading up to that. And, it's still not *guaranteed* that the coder \nwill remember to put the bug# in even that commit message.\n\n>> Basically,\n>> I'm saying that well-named branches can and do carry useful contextual\n>> information that oughtn't to be thrown away. Currently, when you delete\n>> that branch, you lose the branch name altogether.\n>\n> Some would argue that branches are not always well-named... But\n\nBut when they are, why should that info be thrown away? When they're \nnot well-named, they can be ignored (or the branch name recording \nfeature can be turned off!)\n\n> anyway, if the branch ends up getting merged to the mainline, the\n> merge commit defaults to a message like \"Merge branch\n> 'pacman-minigame'\".\n\nOnly if it's a non-ff merge, which results in less tidy commit trees, \nand hence is often recommended against. Whatsmore, tracking down which \nbranch a commit pertains to is still rather difficult using this \napproach. You can go back through the history and find \"Merge branch \n'pacman-minigame'\", but how do you know which commit was the *start* of \nthat branch, if they are not tagged with the branch name?\n\n-- \nBest regards,\nJeremy Morton (Jez)\n"},{"id":"239818","messageId":"CALKQrgemFx=2JaC1BaRqCwEV+knC8QftxcZ7K0AsT9azzuyVdA@mail.gmail.com","threadId":"36508","inReplyTo":"535D4085.4040707@game-point.net","subject":"Re: Recording the current branch on each commit?","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2014-04-27T19:33:05Z","receivedAt":"2014-04-27T19:33:05Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Sun, Apr 27, 2014 at 7:38 PM, Jeremy Morton wrote:\n> On 27/04/2014 10:09, Johan Herland wrote:\n>> On Sun, Apr 27, 2014 at 1:56 AM, Jeremy Morton\n>> wrote:\n>>> Currently, git records a checksum, author, commit date/time, and commit\n>>> message with every commit (as get be seen from 'git log'). I think it\n>>> would\n>>> be useful if, along with the Author and Date, git recorded the name of\n>>> the\n>>> current branch on each commit.\n>>\n>> This has been discussed multiple times in the past. One example here:\n>> http://thread.gmane.org/gmane.comp.version-control.git/229422\n>>\n>> I believe the current conclusion (if any) is that encoding such\n>> information as a _structural_ part of the commit object is not useful.\n>> See the old thread(s) for the actual pro/con arguments.\n>\n> As far as I can tell from that discussion, the general opposition to\n> encoding the branch name as a structural part of the commit object is that,\n> for some people's workflows, it would be unhelpful and/or misleading. Well\n> fair enough then - why don't we make it a setting that is off by default,\n> and can easily be switched on? That way the people for whom tagging the\n> branch name would be useful have a very easy way to switch it on.\n\nObviously, the feature would necessarily have to be optional, simply\nbecause Git would have to keep understanding the old commit object\nformat for a LONG time (probably indefinitely), and there's nothing\nyou can do to prevent others from creating old-style commit objects.\n\nWhich brings us to another big con at this point: The cost of changing\nthe commit object format. One can argue for or against a new commit\nobject format, but the simple truth at this point is that changing the\nstructure of the commit object is expensive. Even if we were all in\nagreement about the change (and so far we are not), there are multiple\nGit implementations (libgit2, jgit, dulwich, etc.) that would all have\nto learn the new commit object, not to mention that bumping\ncore.repositoryformatversion would probably make your git repo\nincompatible with a huge number of existing deployments for the\nforeseeable future.\n\nTherefore, the most pragmatic and constructive thing to do at this\npoint, is IMHO to work within the confines of the existing commit\nobject structure. I actually believe using commit message trailers\nlike \"Made-on-branch: frotz\" in addition to some helpful\ninfrastructure (hooks, templates, git-interpret-trailers, etc.) should\nget you pretty much exactly what you want. And if this feature turns\nout to be extremely useful for a lot of users, we can certainly\nconsider changing the commit object format in the future.\n\n> I know\n> that for the workflows I personally have used in the past, such tagging\n> would be very useful. Quite often I have been looking through the Git log\n> and wondered what feature a commit was \"part of\", because I have feature\n> branches. Just knowing that branch name would be really useful, but the\n> branch has since been deleted... and in the case of a ff-merge (which I\n> thought was recommended in Git if possible), the branch name is completely\n> gone.\n\nTrue. The branch name is - for better or worse - simply not considered\nvery important by Git, and a Git commit is simply not considered (by\nGit at least) to \"be part of\" or otherwise \"belong to\" any branch.\nInstead the commit history/graph is what Git considers important, and\nthe branch names are really just more-or-less ephemeral pointers into\nthat graph.\n\nAFAIK, recording the current branch name in commits was not considered\nto the worth including in Linus' original design, and since then it\nseems to only have come up a few times on the mailing list. This is\nquite central to Git's design, and changing it at this point should\nnot be done lightly.\n\nIINM, Mercurial does this differently, so that may be a better fit for\nthe workflows where keeping track of branch names is very important.\n\n>> That said, you are of course free to add this information to your own\n>> commit messages, by appending something like \"Made-on-branch: frotz\".\n>> In a company setting, you can even create a commit message template or\n>> (prepare-)commit-msg hook to have this line created automatically for\n>> you and your co-workers. You could even append such information\n>> retroactively to existing commits with \"git notes\". There is also the\n>> current interpret-trailers effort by Christian Couder [1] that should\n>> be useful in creating and managing such lines.\n>>\n>> [1]: http://thread.gmane.org/gmane.comp.version-control.git/245874\n>\n> Well I guess that's another way of doing it. So, why aren't Author and Date\n> trailers? They don't seem any more fundamental to me than branch name. I\n> mean the only checkin information you really *need* is the checksum, and\n> commit's parents. The Author and Date are just extra pieces of information\n> you might find useful sometimes, right? A bit like some people might find\n> branch checkin name useful sometimes...?\n\nYeah, sure. Author and Date (and Committer, for that matter) is just\nmetadata, and the current branch name is simply just another kind of\nmetadata. All of them are more-or-less free-form text fields, and off\nthe top of my head, I can't really say that if we were to design Git\nfrom scratch today, they wouldn't all become optional trailers (or\nheaders, or what-have-you).\n\nHowever, we're not designing Git from scratch, and we have to work\nwith what is already there...\n\n>>> The branch name can provide useful\n>>> contextual information. For instance, let's say I'm developing a suite\n>>> of\n>>> games. If the commit message says \"Added basic options dialog\", it might\n>>> be\n>>> useful to see that the branch name is \"pacman-minigame\" indicating that\n>>> the\n>>> commit pertains to the options dialog in the Pacman minigame.\n>>\n>> In that partcular case, ISTM that the context (\"pacman-minigame\")\n>> would actually be better preserved elsewhere. E.g. the commits touch\n>> files in a particular \"minigames/pacman\" subdir, or you prefix the\n>> context in the commit message (\"pacman-minigame: Added basic options\n>> dialog\"). Also, such a \"topic\" branch is often tied to a specific\n>\n> Again, this is a pain because you have to remember to manually tag every\n> commit message with \"pacman-minigame\", and it takes up precious space in the\n> (already short) commit message.\n\nYes, which is why I advise you to look at commit message templates,\nhooks, and interpret-trailers to see if you can find a way to automate\nthis for you and your co-workers.\n\n[...]\n\n>> anyway, if the branch ends up getting merged to the mainline, the\n>> merge commit defaults to a message like \"Merge branch\n>> 'pacman-minigame'\".\n>\n> Only if it's a non-ff merge, which results in less tidy commit trees, and\n> hence is often recommended against.\n\nNot at all. If you're developing a series of commits with a common\npurpose (a.k.a. a topic branch) I would very much argue for\nnon-ff-merging this, _exactly_ because the merge commit allows you to\nintroduce the entire topic as a single entity. The merge commit\nmessage (in addition to containing the branch name) is also the\nnatural place to describe more general things about the topic as a\nwhole - sort of like the cover letter to a patch series.\n\nThe problem is not really \"less tidy commit trees\" - by which I gather\nyou mean history graphs that are non-linear. IMHO, the history graph\nshould reflect parallel/branched development when that is useful.\nBlindly rebasing everything into a single line is IMHO just as bad as\ndoing all your work directly on master and blindly running \"git pull\"\nbetween each of your own commits (which results in a lot of useless\nmerges). The merge commits themselves are not the problem. Merge\ncommits are a tool, and when used properly (to introduce topics to the\nmaster branch like described above) they are a good tool. When abused\n(like blindly running \"git pull\" and accepting useless \"merge\nbubbles\") they create more problems than they solve.\n\n> Whatsmore, tracking down which branch a\n> commit pertains to is still rather difficult using this approach. You can\n> go back through the history and find \"Merge branch 'pacman-minigame'\", but\n> how do you know which commit was the *start* of that branch, if they are not\n> tagged with the branch name?\n\nOnce you have found the merge commit (M), git log M^1..M^2 should list\nall the commits that were made on that branch. The parent of the last\nin that list can be considered the starting point for the branch.\n\n\nHope this helps,\n\n...Johan\n\n-- \nJohan Herland, \nwww.herland.net\n"},{"id":"239823","messageId":"535D6EB1.9080208@game-point.net","threadId":"36508","inReplyTo":"CALKQrgemFx=2JaC1BaRqCwEV+knC8QftxcZ7K0AsT9azzuyVdA@mail.gmail.com","subject":"Re: Recording the current branch on each commit?","fromName":"Jeremy Morton","fromEmail":"admin@game-point.net","sentAt":"2014-04-27T20:55:13Z","receivedAt":"2014-04-27T20:55:13Z","isPatch":false,"sender":{"key":"admin@game-point.net","avatar":null},"body":"On 27/04/2014 20:33, Johan Herland wrote:\n> On Sun, Apr 27, 2014 at 7:38 PM, Jeremy Morton wrote:\n>> On 27/04/2014 10:09, Johan Herland wrote:\n>> As far as I can tell from that discussion, the general opposition to\n>> encoding the branch name as a structural part of the commit object is that,\n>> for some people's workflows, it would be unhelpful and/or misleading. Well\n>> fair enough then - why don't we make it a setting that is off by default,\n>> and can easily be switched on? That way the people for whom tagging the\n>> branch name would be useful have a very easy way to switch it on.\n>\n> Therefore, the most pragmatic and constructive thing to do at this\n> point, is IMHO to work within the confines of the existing commit\n> object structure. I actually believe using commit message trailers\n> like \"Made-on-branch: frotz\" in addition to some helpful\n> infrastructure (hooks, templates, git-interpret-trailers, etc.) should\n> get you pretty much exactly what you want. And if this feature turns\n> out to be extremely useful for a lot of users, we can certainly\n> consider changing the commit object format in the future.\n\nOK, fair enough. So I guess what I'd like to see, then, is good \nbuilt-in functionality in Git for these commit message trailers, so that \nthey are very easy to turn on. I'd like to be able to tell \nco-developers to add a one-liner to their git config file rather than \nsome post-commit script.\n\n>> I know\n>> that for the workflows I personally have used in the past, such tagging\n>> would be very useful. Quite often I have been looking through the Git log\n>> and wondered what feature a commit was \"part of\", because I have feature\n>> branches. Just knowing that branch name would be really useful, but the\n>> branch has since been deleted... and in the case of a ff-merge (which I\n>> thought was recommended in Git if possible), the branch name is completely\n>> gone.\n>\n> True. The branch name is - for better or worse - simply not considered\n> very important by Git, and a Git commit is simply not considered (by\n> Git at least) to \"be part of\" or otherwise \"belong to\" any branch.\n\nPlease understand that I know this full well. :-) I'm saying that the \n'ephemeral' pointers' names are, in themselves, useful - if, like me, \nyou give them meaningful names. What I'm proposing is pretty much an \nautomatic tagging (somehow...) of each commit with the current branch \nname (if one is available); information that carries roughly the same \nweight as the commit message. It could be crap, but equally it could be \nvery useful, in some workflows. I think most of us can agree on that.\n\n> seems to only have come up a few times on the mailing list. This is\n\nBut it has come up more than once, which would seem to indicate that I'm \nnot the only one with this request. ;-)\n\n> IINM, Mercurial does this differently, so that may be a better fit for\n\n\"If I'm Not Mistaken\" - I had to look that one up.\n\n> the workflows where keeping track of branch names is very important.\n\nNah, I had a look at Mercurial and I think I prefer Git - this branch \nname thing is just my one bugbear. I definitely prefer Git's concept of \na staging area rather than just committing all changes. To do that in \nMercurial you have to use mq and all the different (IMHO unintuative) \ncommands that entails, and if you accidentally \"mq commit\" then you \nscrew everything up. :-) Mercurial also discourages history rewriting \n(ie. cleaning up of messy commits), which Git doesn't. I prefer Git's \napproach here too.\n\n> Yeah, sure. Author and Date (and Committer, for that matter) is just\n> metadata, and the current branch name is simply just another kind of\n> metadata. All of them are more-or-less free-form text fields, and off\n> the top of my head, I can't really say that if we were to design Git\n> from scratch today, they wouldn't all become optional trailers (or\n> headers, or what-have-you).\n>\n> However, we're not designing Git from scratch, and we have to work\n> with what is already there...\n\nFair point.\n\n>>>> The branch name can provide useful\n>>>> contextual information. For instance, let's say I'm developing a suite\n>>>> of\n>>>> games. If the commit message says \"Added basic options dialog\", it might\n>>>> be\n>>>> useful to see that the branch name is \"pacman-minigame\" indicating that\n>>>> the\n>>>> commit pertains to the options dialog in the Pacman minigame.\n>>>\n>>> In that partcular case, ISTM that the context (\"pacman-minigame\")\n>>> would actually be better preserved elsewhere. E.g. the commits touch\n>>> files in a particular \"minigames/pacman\" subdir, or you prefix the\n>>> context in the commit message (\"pacman-minigame: Added basic options\n>>> dialog\"). Also, such a \"topic\" branch is often tied to a specific\n>>\n>> Again, this is a pain because you have to remember to manually tag every\n>> commit message with \"pacman-minigame\", and it takes up precious space in the\n>> (already short) commit message.\n>\n> Yes, which is why I advise you to look at commit message templates,\n> hooks, and interpret-trailers to see if you can find a way to automate\n> this for you and your co-workers.\n\nWhat I'd like to see, then, is this trailer functionality built in to \nGit so that a very minimal amount of setup is needed to get everybody \nusing it. We're basically talking about hijacking the commit messages \nand tacking on information that they weren't really intended to hold \n(ie. stuff the developer hasn't manually typed in as a commit message), \nbecause of the limitation of the Git commit format. In hindsight, I \nguess it would've been better to have the Git commit format be more \nflexible in terms of what headers it allows, so that new headers could \neasily be added and some headers could be optional.\n\n>> Only if it's a non-ff merge, which results in less tidy commit trees, and\n>> hence is often recommended against.\n>\n> Not at all. If you're developing a series of commits with a common\n> purpose (a.k.a. a topic branch) I would very much argue for\n> non-ff-merging this, _exactly_ because the merge commit allows you to\n> introduce the entire topic as a single entity. The merge commit\n> message (in addition to containing the branch name) is also the\n> natural place to describe more general things about the topic as a\n> whole - sort of like the cover letter to a patch series.\n\nWould you recommend that every single commit be made in a branch that \ngets merged into master, then? So, no direct commits to master?\n\n> The problem is not really \"less tidy commit trees\" - by which I gather\n> you mean history graphs that are non-linear. IMHO, the history graph\n> should reflect parallel/branched development when that is useful.\n> Blindly rebasing everything into a single line is IMHO just as bad as\n> doing all your work directly on master and blindly running \"git pull\"\n> between each of your own commits (which results in a lot of useless\n> merges). The merge commits themselves are not the problem. Merge\n> commits are a tool, and when used properly (to introduce topics to the\n> master branch like described above) they are a good tool. When abused\n> (like blindly running \"git pull\" and accepting useless \"merge\n> bubbles\") they create more problems than they solve.\n\nSounds like the default behaviour of \"git pull\" might not be ideal if it \neasily causes these problems.\n\n>> Whatsmore, tracking down which branch a\n>> commit pertains to is still rather difficult using this approach. You can\n>> go back through the history and find \"Merge branch 'pacman-minigame'\", but\n>> how do you know which commit was the *start* of that branch, if they are not\n>> tagged with the branch name?\n>\n> Once you have found the merge commit (M), git log M^1..M^2 should list\n> all the commits that were made on that branch. The parent of the last\n> in that list can be considered the starting point for the branch.\n\nI don't quite understand this; your suggestion would only work on the \nassumption that no merges have been made from master to that branch; git \nlog M^1..M^2 will get the most recent common ancestor of the two and \nshow the commits between them, but if there has been a merge from master \nto branch, it will not show the commits to the branch before that \nmerge... so it's not as useful as tagging. You'd have to do some work \nto get all the branch's commits, which is rather undesirable when you \ncould just see the branch name (when perusing 'git log') if it were \ntagged as part of the commit.\n\n> Hope this helps,\n>\n> ...Johan\n\n-- \nBest regards,\nJeremy Morton (Jez)\n"},{"id":"239824","messageId":"53a594dd-cd3d-4b33-ada8-3d7e08b86ee2@email.android.com","threadId":"36508","inReplyTo":"535D3DF8.4020904@game-point.net","subject":"Re: Recording the current branch on each commit?","fromName":"James Denholm","fromEmail":"nod.helm@gmail.com","sentAt":"2014-04-27T21:40:27Z","receivedAt":"2014-04-27T21:40:27Z","isPatch":false,"sender":{"key":"nod.helm@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1721189?v=4"},"body":"I'm skipping a lot of the discussion here, sorry about that, but\non one particular note:\n\nJeremy Morton wrote:\n> (...) and besides it takes up space that could be \n>used for a commit message. As short commit messages are valued in Git,\n>it's particularly bad to waste space this way.\n\nNot really. While different groups will have different values, the\n\"greater git community\" seems to prefer short _first lines_,\nof fifty chars or less, while the _body_ should be as verbose as\nit needs to be (but not more than). Ergo, while the first\nline shouldn't contain a swath of metadata, the body can\neasily.\n\nA particularly good example of this is almost every commit to\nthe git project itself - there are\"Signed-of-by\" lines and such\neverywhere in the logs.\n\n>Also, you don't always have something you can link a commit to in an \n>issue tracker. You may just be implementing a feature that has been \n>agreed upon, independently of any such tracker. In that case, there's \n>no bug# to link to.\n\nIn which case, refer to whatever system you use. If you aren't\nusing a ticketing system, have the line \"Relates-to: Water\ncooler conversation with Bob on July 28th\" or whatever the\npatches relate to.\n\n(Arguably, though, the better solution is to use a ticketing\nsystem, or anything that allows discussion to be easily\nreferenced.)\n\nRegards,\nJames Denholm.\n"},{"id":"239825","messageId":"535D80EB.2090701@game-point.net","threadId":"36508","inReplyTo":"53a594dd-cd3d-4b33-ada8-3d7e08b86ee2@email.android.com","subject":"Re: Recording the current branch on each commit?","fromName":"Jeremy Morton","fromEmail":"admin@game-point.net","sentAt":"2014-04-27T22:12:59Z","receivedAt":"2014-04-27T22:12:59Z","isPatch":false,"sender":{"key":"admin@game-point.net","avatar":null},"body":"On 27/04/2014 22:40, James Denholm wrote:\n>> Also, you don't always have something you can link a commit to in an\n>> issue tracker. You may just be implementing a feature that has been\n>> agreed upon, independently of any such tracker. In that case, there's\n>> no bug# to link to.\n>\n> In which case, refer to whatever system you use. If you aren't\n> using a ticketing system, have the line \"Relates-to: Water\n> cooler conversation with Bob on July 28th\" or whatever the\n> patches relate to.\n>\n> (Arguably, though, the better solution is to use a ticketing\n> system, or anything that allows discussion to be easily\n> referenced.)\n\nWell, as I said elsewhere in this discussion, Git should provide that \nfunctionality built-in, IMHO. It would be good to be able to set a \none-liner in my .gitconfig to tag each commit with a \"branch checked \ninto\" trailer.\n\n-- \nBest regards,\nJeremy Morton (Jez)\n"},{"id":"239826","messageId":"2c8517bf-baf8-46ae-b6f8-88d0a3106a74@email.android.com","threadId":"36508","inReplyTo":"535D80EB.2090701@game-point.net","subject":"Re: Recording the current branch on each commit?","fromName":"James Denholm","fromEmail":"nod.helm@gmail.com","sentAt":"2014-04-27T22:31:30Z","receivedAt":"2014-04-27T22:31:30Z","isPatch":false,"sender":{"key":"nod.helm@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1721189?v=4"},"body":"Jeremy Morton wrote:\n>On 27/04/2014 22:40, James Denholm wrote:\n>>> Also, you don't always have something you can link a commit to in an\n>>> issue tracker. You may just be implementing a feature that has been\n>>> agreed upon, independently of any such tracker. In that case,\n>there's\n>>> no bug# to link to.\n>>\n>> In which case, refer to whatever system you use. If you aren't\n>> using a ticketing system, have the line \"Relates-to: Water\n>> cooler conversation with Bob on July 28th\" or whatever the\n>> patches relate to.\n>>\n>> (Arguably, though, the better solution is to use a ticketing\n>> system, or anything that allows discussion to be easily\n>> referenced.)\n>\n>Well, as I said elsewhere in this discussion, Git should provide that \n>functionality built-in, IMHO. It would be good to be able to set a \n>one-liner in my .gitconfig to tag each commit with a \"branch checked \n>into\" trailer.\n\nIn that case, write something onto your post-commit hook and the\nfunctionality would be achieved. A relates-to line doesn't need a\nchange to the structure of git commits.\n"},{"id":"239827","messageId":"CALKQrgdFLc=k9i1+N2458amLMGQa99q55A=N785VfMRwfOH6Rg@mail.gmail.com","threadId":"36508","inReplyTo":"535D6EB1.9080208@game-point.net","subject":"Re: Recording the current branch on each commit?","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2014-04-27T23:39:26Z","receivedAt":"2014-04-27T23:39:26Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Sun, Apr 27, 2014 at 10:55 PM, Jeremy Morton wrote:\n> On 27/04/2014 20:33, Johan Herland wrote:\n>> On Sun, Apr 27, 2014 at 7:38 PM, Jeremy Morton\n>> wrote:\n>>> On 27/04/2014 10:09, Johan Herland wrote:\n>>> As far as I can tell from that discussion, the general opposition to\n>>> encoding the branch name as a structural part of the commit object is\n>>> that,\n>>> for some people's workflows, it would be unhelpful and/or misleading.\n>>> Well\n>>> fair enough then - why don't we make it a setting that is off by default,\n>>> and can easily be switched on? That way the people for whom tagging the\n>>> branch name would be useful have a very easy way to switch it on.\n>>\n>> Therefore, the most pragmatic and constructive thing to do at this\n>> point, is IMHO to work within the confines of the existing commit\n>> object structure. I actually believe using commit message trailers\n>> like \"Made-on-branch: frotz\" in addition to some helpful\n>> infrastructure (hooks, templates, git-interpret-trailers, etc.) should\n>> get you pretty much exactly what you want. And if this feature turns\n>> out to be extremely useful for a lot of users, we can certainly\n>> consider changing the commit object format in the future.\n>\n> OK, fair enough. So I guess what I'd like to see, then, is good built-in\n> functionality in Git for these commit message trailers, so that they are\n> very easy to turn on. I'd like to be able to tell co-developers to add a\n> one-liner to their git config file rather than some post-commit script.\n\nI think this is what the interpret-trailers effort is about.\nUnfortunately I have not followed it closely enough to say if your use\ncase is already covered by Christian's (CCed) work. Christian: With\nyour current patch series, is it possible for Jeremy to configure\ninterpret-trailers to automatically append a \"Made-on-branch:\n\" trailer whenever he creates a commit?\n\n[...]\n\n> What I'd like to see, then, is this trailer functionality built in to Git so\n> that a very minimal amount of setup is needed to get everybody using it.\n> We're basically talking about hijacking the commit messages and tacking on\n> information that they weren't really intended to hold (ie. stuff the\n> developer hasn't manually typed in as a commit message), because of the\n> limitation of the Git commit format. In hindsight, I guess it would've been\n> better to have the Git commit format be more flexible in terms of what\n> headers it allows, so that new headers could easily be added and some\n> headers could be optional.\n\nWhich - if you squint at it a little - is sort of what the\ninterpret-trailers effort does. AFAIK, it (combined with hooks) allows\nyou to configure a set of optional s/headers/trailers/ and the\npolicies surrounding those.\n\n>>> Only if it's a non-ff merge, which results in less tidy commit trees, and\n>>> hence is often recommended against.\n>>\n>> Not at all. If you're developing a series of commits with a common\n>> purpose (a.k.a. a topic branch) I would very much argue for\n>> non-ff-merging this, _exactly_ because the merge commit allows you to\n>> introduce the entire topic as a single entity. The merge commit\n>> message (in addition to containing the branch name) is also the\n>> natural place to describe more general things about the topic as a\n>> whole - sort of like the cover letter to a patch series.\n>\n> Would you recommend that every single commit be made in a branch that gets\n> merged into master, then? So, no direct commits to master?\n\nThere are a lot of variables here, and it really comes down to your\n(team's) preferred workflow. Different teams/people prefer different\nworkflows, and git's toolbox allows a wide (probably the widest among\nany VCS) variety of workflows to be expressed. So I really cannot make\nany sweeping/simple recommendations that will apply to all cases.\n\nAlthough I prefer collecting related commits on a topic branch that\nare then (non-ff) merged into master, I also see the value of\nperforming a quick single-commit bugfix directly on master. In the\nlatter case, the commit should obviously be self-sufficient and\nself-explanatory. However, once your work start spanning more than a\nfew commits, you should really think about putting it on a separate\nbranch, where it can be (re)organized in a way that is logical and\nreviewable (interactive rebase FTW).\n\nWhen I think about it, this might only apply to centralized workflows\nwhere team members (typically co-workers) push their own work to a\nshared repository/branch. As a counterexample: in git.git, pretty much\nevery change (whether it consists of a single patch, or a series of\npatches) gets its own \"$who/$what\" branch in Junio's tree, and are\nthen merged to 'pu'. When deemed worthy, they are merged to 'next' and\n- later - to 'master'. So here, even single-commit changes get their\nown branch and subsequent merge commit. Likewise, with GitHub's\npull-request workflow, you make changes on a branch in one repo, and\nthen request that branch to be pulled (i.e. merged) into another repo,\nregardless of whether it consists of one or many commits.\n\nHowever, one sweeping recommendation that I _can_ make across all\nworkflows is this: _Think_ about your commit history. Treat it with\nthe same respect and attention to quality as your code (or whatever\nyour \"main\" work product is). A well-organized history with good\ncommit messages is an invaluable tool in grokking how the current\nstate of a project has come to be, and it encodes a great deal of\nknowledge about the project from its developers, and can be of great\nhelp when debugging.\n\n>> The problem is not really \"less tidy commit trees\" - by which I gather\n>> you mean history graphs that are non-linear. IMHO, the history graph\n>> should reflect parallel/branched development when that is useful.\n>> Blindly rebasing everything into a single line is IMHO just as bad as\n>> doing all your work directly on master and blindly running \"git pull\"\n>> between each of your own commits (which results in a lot of useless\n>> merges). The merge commits themselves are not the problem. Merge\n>> commits are a tool, and when used properly (to introduce topics to the\n>> master branch like described above) they are a good tool. When abused\n>> (like blindly running \"git pull\" and accepting useless \"merge\n>> bubbles\") they create more problems than they solve.\n>\n> Sounds like the default behaviour of \"git pull\" might not be ideal if it\n> easily causes these problems.\n\nAgreed, and I believe Junio has also stated that the default behavior\nof \"git pull\" is better suited for maintainers (like Junio and Linus)\nthat pull from downstreams, rather than regular\ncontributors/co-workers that more often pull from their upstream. \"git\npull --rebase\" (or branch..rebase, or even\nbranch.autosetuprebase) is one way to work around that, but even that\ncan also be abused if you do in indiscriminately (can lead to\ndifferent topics being interleaved in-line on master, which makes it\nhard to identify which commits belong to which topic). Again, the\nideal is for people to think about what they're doing, and not just\nrun commands blindly...\n\n>>> Whatsmore, tracking down which branch a\n>>> commit pertains to is still rather difficult using this approach. You\n>>> can\n>>> go back through the history and find \"Merge branch 'pacman-minigame'\",\n>>> but\n>>> how do you know which commit was the *start* of that branch, if they are\n>>> not\n>>> tagged with the branch name?\n>>\n>> Once you have found the merge commit (M), git log M^1..M^2 should list\n>> all the commits that were made on that branch. The parent of the last\n>> in that list can be considered the starting point for the branch.\n>\n> I don't quite understand this; your suggestion would only work on the\n> assumption that no merges have been made from master to that branch; git log\n> M^1..M^2 will get the most recent common ancestor of the two and show the\n> commits between them, but if there has been a merge from master to branch,\n> it will not show the commits to the branch before that merge...\n\nActually no, \"git log M^1..M^2\" shows you all commits reachable from\nM^2 that are not reachable from M^1, and assuming your merge went\n_from_ master and _to_ the branch (NOT the other way), it will show\nall the commits to the branch (3 x A + 3 x B). Illustration:\n\n o---o---o---o---o---o---o---M <-- master\n \\ \\ /\n A---A---A---m---B---B---B <-- branch\n\nThe initial commits (3 x A) on the branch before the intermediate\nmerge from master (m) are not reachable from M^1 (the last 'o' before\nM), thus they _will_ show up in \"git log M^1..M^2\". This holds no\nmatter how many merges are done from master to branch.\n\nObviously, if the merge had gone the other way, like this:\n\n o---o---o---m---o---o---M <-- master\n \\ / /\n A---A---A---B---B---B <-- branch\n\nthen the initial branch commits (3 x A) preceding 'm', will not be\nshown by \"git log M^1..M^2\", but that is because they have already\nentered the master branch (at m). Whether you still consider them part\nof the same branch as the 3 x B commits is really a philosophical\nquestion at that point.\n\n\n...Johan\n\n-- \nJohan Herland, \nwww.herland.net\n"},{"id":"239828","messageId":"535DBD35.4080507@gmail.com","threadId":"36508","inReplyTo":"CALKQrgemFx=2JaC1BaRqCwEV+knC8QftxcZ7K0AsT9azzuyVdA@mail.gmail.com","subject":"Re: Recording the current branch on each commit?","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2014-04-28T02:30:13Z","receivedAt":"2014-04-28T02:30:13Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"On 04/28/2014 01:03 AM, Johan Herland wrote:\n> On Sun, Apr 27, 2014 at 7:38 PM, Jeremy Morton wrote:\n>> On 27/04/2014 10:09, Johan Herland wrote:\n>>> On Sun, Apr 27, 2014 at 1:56 AM, Jeremy Morton\n>>> wrote:\n>>>> Currently, git records a checksum, author, commit date/time, and commit\n>>>> message with every commit (as get be seen from 'git log'). I think it\n>>>> would\n>>>> be useful if, along with the Author and Date, git recorded the name of\n>>>> the\n>>>> current branch on each commit.\n>>>\n>>> This has been discussed multiple times in the past. One example here:\n>>> http://thread.gmane.org/gmane.comp.version-control.git/229422\n>>>\n>>> I believe the current conclusion (if any) is that encoding such\n>>> information as a _structural_ part of the commit object is not useful.\n>>> See the old thread(s) for the actual pro/con arguments.\n>>\n>> As far as I can tell from that discussion, the general opposition to\n>> encoding the branch name as a structural part of the commit object is that,\n>> for some people's workflows, it would be unhelpful and/or misleading. Well\n>> fair enough then - why don't we make it a setting that is off by default,\n>> and can easily be switched on? That way the people for whom tagging the\n>> branch name would be useful have a very easy way to switch it on.\n>\n> Obviously, the feature would necessarily have to be optional, simply\n> because Git would have to keep understanding the old commit object\n> format for a LONG time (probably indefinitely), and there's nothing\n> you can do to prevent others from creating old-style commit objects.\n>\n> Which brings us to another big con at this point: The cost of changing\n> the commit object format. One can argue for or against a new commit\n> object format, but the simple truth at this point is that changing the\n> structure of the commit object is expensive. Even if we were all in\n> agreement about the change (and so far we are not), there are multiple\n> Git implementations (libgit2, jgit, dulwich, etc.) that would all have\n> to learn the new commit object, not to mention that bumping\n> core.repositoryformatversion would probably make your git repo\n> incompatible with a huge number of existing deployments for the\n> foreseeable future.\n>\n> Therefore, the most pragmatic and constructive thing to do at this\n> point, is IMHO to work within the confines of the existing commit\n> object structure. I actually believe using commit message trailers\n> like \"Made-on-branch: frotz\" in addition to some helpful\n> infrastructure (hooks, templates, git-interpret-trailers, etc.) should\n> get you pretty much exactly what you want. And if this feature turns\n> out to be extremely useful for a lot of users, we can certainly\n> consider changing the commit object format in the future.\n>\n>> I know\n>> that for the workflows I personally have used in the past, such tagging\n>> would be very useful. Quite often I have been looking through the Git log\n>> and wondered what feature a commit was \"part of\", because I have feature\n>> branches. Just knowing that branch name would be really useful, but the\n>> branch has since been deleted... and in the case of a ff-merge (which I\n>> thought was recommended in Git if possible), the branch name is completely\n>> gone.\n>\n> True. The branch name is - for better or worse - simply not considered\n> very important by Git, and a Git commit is simply not considered (by\n> Git at least) to \"be part of\" or otherwise \"belong to\" any branch.\n> Instead the commit history/graph is what Git considers important, and\n> the branch names are really just more-or-less ephemeral pointers into\n> that graph.\n>\n> AFAIK, recording the current branch name in commits was not considered\n> to the worth including in Linus' original design, and since then it\n> seems to only have come up a few times on the mailing list. This is\n> quite central to Git's design, and changing it at this point should\n> not be done lightly.\n>\n> IINM, Mercurial does this differently, so that may be a better fit for\n> the workflows where keeping track of branch names is very important.\n>\n>>> That said, you are of course free to add this information to your own\n>>> commit messages, by appending something like \"Made-on-branch: frotz\".\n>>> In a company setting, you can even create a commit message template or\n>>> (prepare-)commit-msg hook to have this line created automatically for\n>>> you and your co-workers. You could even append such information\n>>> retroactively to existing commits with \"git notes\". There is also the\n>>> current interpret-trailers effort by Christian Couder [1] that should\n>>> be useful in creating and managing such lines.\n>>>\n>>> [1]: http://thread.gmane.org/gmane.comp.version-control.git/245874\n>>\n>> Well I guess that's another way of doing it. So, why aren't Author and Date\n>> trailers? They don't seem any more fundamental to me than branch name. I\n>> mean the only checkin information you really *need* is the checksum, and\n>> commit's parents. The Author and Date are just extra pieces of information\n>> you might find useful sometimes, right? A bit like some people might find\n>> branch checkin name useful sometimes...?\n>\n> Yeah, sure. Author and Date (and Committer, for that matter) is just\n> metadata, and the current branch name is simply just another kind of\n> metadata. All of them are more-or-less free-form text fields, and off\n\nno they're not. In strictly controlled environments they form part of\nthe audit record for the source code.\n\nYes they can be faked (explicitly), but -- again in strictly controlled\nenvironments -- that can be limited to \"before it was first pushed\".\n"},{"id":"239831","messageId":"87zjj656my.fsf@fencepost.gnu.org","threadId":"36508","inReplyTo":"CALKQrgemFx=2JaC1BaRqCwEV+knC8QftxcZ7K0AsT9azzuyVdA@mail.gmail.com","subject":"Re: Recording the current branch on each commit?","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2014-04-28T06:07:33Z","receivedAt":"2014-04-28T06:07:33Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Johan Herland writes:\n\n> Obviously, the feature would necessarily have to be optional, simply\n> because Git would have to keep understanding the old commit object\n> format for a LONG time (probably indefinitely), and there's nothing\n> you can do to prevent others from creating old-style commit objects.\n\nPersonally, I am _strongly_ opposed. How I name and juggle my private\nbranches is nobody else's business in a distributed version control\nsystem.\n\nThey are private. My personal workflow. Not part of a commit.\n\n-- \nDavid Kastrup\n"},{"id":"239836","messageId":"20140428.084543.1615507400056684596.chriscool@tuxfamily.org","threadId":"36508","inReplyTo":"CALKQrgdFLc=k9i1+N2458amLMGQa99q55A=N785VfMRwfOH6Rg@mail.gmail.com","subject":"Re: Recording the current branch on each commit?","fromName":"Christian Couder","fromEmail":"chriscool@tuxfamily.org","sentAt":"2014-04-28T06:45:43Z","receivedAt":"2014-04-28T06:45:43Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"From: Johan Herland \nSubject: Re: Recording the current branch on each commit?\nDate: Mon, 28 Apr 2014 01:39:26 +0200\n\n> On Sun, Apr 27, 2014 at 10:55 PM, Jeremy Morton wrote:\n>> On 27/04/2014 20:33, Johan Herland wrote:\n>>> On Sun, Apr 27, 2014 at 7:38 PM, Jeremy Morton\n>>> wrote:\n>>>> On 27/04/2014 10:09, Johan Herland wrote:\n>>>> As far as I can tell from that discussion, the general opposition to\n>>>> encoding the branch name as a structural part of the commit object is\n>>>> that,\n>>>> for some people's workflows, it would be unhelpful and/or misleading.\n>>>> Well\n>>>> fair enough then - why don't we make it a setting that is off by default,\n>>>> and can easily be switched on? That way the people for whom tagging the\n>>>> branch name would be useful have a very easy way to switch it on.\n>>>\n>>> Therefore, the most pragmatic and constructive thing to do at this\n>>> point, is IMHO to work within the confines of the existing commit\n>>> object structure. I actually believe using commit message trailers\n>>> like \"Made-on-branch: frotz\" in addition to some helpful\n>>> infrastructure (hooks, templates, git-interpret-trailers, etc.) should\n>>> get you pretty much exactly what you want. And if this feature turns\n>>> out to be extremely useful for a lot of users, we can certainly\n>>> consider changing the commit object format in the future.\n>>\n>> OK, fair enough. So I guess what I'd like to see, then, is good built-in\n>> functionality in Git for these commit message trailers, so that they are\n>> very easy to turn on. I'd like to be able to tell co-developers to add a\n>> one-liner to their git config file rather than some post-commit script.\n> \n> I think this is what the interpret-trailers effort is about.\n> Unfortunately I have not followed it closely enough to say if your use\n> case is already covered by Christian's (CCed) work. Christian: With\n> your current patch series, is it possible for Jeremy to configure\n> interpret-trailers to automatically append a \"Made-on-branch:\n> \" trailer whenever he creates a commit?\n\nYes, it's possible. Yesterday, I sent the following patch:\n\n[RFC/PATCH 2/2] trailer: add examples to the documentation\n\nand it shows a commit-msg hook to do something like that:\n\n$ cat >.git/hooks/commit-msg < \"\\$1.new\"\nmv \"\\$1.new\" \"\\$1\"\nEOF\n$ chmod +x .git/hooks/commit-msg\n\nI think you just need to use the following if you want the branch\ninstead of the git version:\n\ngit interpret-trailers --trim-empty --trailer \"git-branch: \\$(git name-rev --name-only HEAD)\" \"\\$1\" > \"\\$1.new\"\n\nIt could even be simpler if there was an option (which has already\nbeen discussed) that made it possible to modify the file in\nplace. This way one would not need the 'mv \"\\$1.new\" \"\\$1\"' command.\n\nBest,\nChristian.\n"},{"id":"239841","messageId":"535e12389eb8d_338911e930c9c@nysa.notmuch","threadId":"36508","inReplyTo":"535D3DF8.4020904@game-point.net","subject":"Re: Recording the current branch on each commit?","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-28T08:32:56Z","receivedAt":"2014-04-28T08:32:56Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Jeremy Morton wrote:\n> On 27/04/2014 09:51, Robin Rosenberg wrote:\n> >> Currently, git records a checksum, author, commit date/time, and commit\n> >> message with every commit (as get be seen from 'git log'). I think it\n> >> would be useful if, along with the Author and Date, git recorded the\n> >> name of the current branch on each commit. The branch name can provide\n> >> useful contextual information. For instance, let's say I'm developing a\n> >> suite of games. If the commit message says \"Added basic options\n> >> dialog\", it might be useful to see that the branch name is\n> >> \"pacman-minigame\" indicating that the commit pertains to the options\n> >> dialog in the Pacman minigame. Basically, I'm saying that well-named\n> >> branches can and do carry useful contextual information that oughtn't to\n> >> be thrown away. Currently, when you delete that branch, you lose the\n> >> branch name altogether.\n> >>\n> >> So what do you think? Would it be good to have a patch to add this feature?\n> >\n> > Branch names are usually poorly named, so often you don't lose much. One way\n> \n> Speak for yourself - I give my branches useful names. :-)\n\nMe too.\n\n> I definitely feel that I am often losing useful contextual information by\n> throwing away the branch name.\n\nI don't.\n\n> > some people to is to always merge with --no-ff, that way you see the branch\n> > name in the merge commit.\n> \n> But surely, it's recommended with Git that you try to avoid doing \n> --no-ff merges to avoid commit noise?\n\nNope. Different people have different needs, there's no recommendation. If\nanything, the recommendation is to do a ff merge, because that's the default.\n\n> Also, it is a lot more hassle (and no doubt, CPU cycles) to track down where\n> a branch was merged to try and figure out which branch name a commit\n> pertained to, not to mention the fact that the commit could've been moved\n> since. Nothing short of tagging the commit with the branch name when the\n> commit is made will definitely record the branch name at the time of\n> committing.\n\nBut why do you need that information?\n\n-- \nFelipe Contreras\n"},{"id":"239844","messageId":"535E1622.70608@game-point.net","threadId":"36508","inReplyTo":"535e12389eb8d_338911e930c9c@nysa.notmuch","subject":"Re: Recording the current branch on each commit?","fromName":"Jeremy Morton","fromEmail":"admin@game-point.net","sentAt":"2014-04-28T08:49:38Z","receivedAt":"2014-04-28T08:49:38Z","isPatch":false,"sender":{"key":"admin@game-point.net","avatar":null},"body":"On 28/04/2014 09:32, Felipe Contreras wrote:\n>>> some people to is to always merge with --no-ff, that way you see the branch\n>>> name in the merge commit.\n>>\n>> But surely, it's recommended with Git that you try to avoid doing\n>> --no-ff merges to avoid commit noise?\n>\n> Nope. Different people have different needs, there's no recommendation. If\n> anything, the recommendation is to do a ff merge, because that's the default.\n\nThat's what I'm saying. With an ff merge, you don't get the merge \ncommit message telling you the branch name.\n\n>> Also, it is a lot more hassle (and no doubt, CPU cycles) to track down where\n>> a branch was merged to try and figure out which branch name a commit\n>> pertained to, not to mention the fact that the commit could've been moved\n>> since. Nothing short of tagging the commit with the branch name when the\n>> commit is made will definitely record the branch name at the time of\n>> committing.\n>\n> But why do you need that information?\n\nAs I said before, I usually consider my branch names useful information \nworth keeping around - I'm not sure why you don't. I might include a \nbug# in the branch name so I don't have to keep typing it in every \ncommit message, or I might just have a handy short description of what \npart of the application this branch is modifying (like my \n\"pacman-minigame\" example).\n\n-- \nBest regards,\nJeremy Morton (Jez)\n"},{"id":"239847","messageId":"535e165364bc5_338911e930cdf@nysa.notmuch","threadId":"36508","inReplyTo":"535D4085.4040707@game-point.net","subject":"Re: Recording the current branch on each commit?","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-28T08:50:27Z","receivedAt":"2014-04-28T08:50:27Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Jeremy Morton wrote:\n> On 27/04/2014 10:09, Johan Herland wrote:\n> > On Sun, Apr 27, 2014 at 1:56 AM, Jeremy Morton wrote:\n> >> Currently, git records a checksum, author, commit date/time, and commit\n> >> message with every commit (as get be seen from 'git log'). I think it would\n> >> be useful if, along with the Author and Date, git recorded the name of the\n> >> current branch on each commit.\n> >\n> > This has been discussed multiple times in the past. One example here:\n> > http://thread.gmane.org/gmane.comp.version-control.git/229422\n> >\n> > I believe the current conclusion (if any) is that encoding such\n> > information as a _structural_ part of the commit object is not useful.\n> > See the old thread(s) for the actual pro/con arguments.\n> \n> As far as I can tell from that discussion, the general opposition to \n> encoding the branch name as a structural part of the commit object is \n> that, for some people's workflows, it would be unhelpful and/or \n> misleading.\n\ns/some people's workflows/most workflows/\n\n> Well fair enough then - why don't we make it a setting that \n> is off by default, and can easily be switched on? That way the people \n> for whom tagging the branch name would be useful have a very easy way to \n> switch it on. I know that for the workflows I personally have used in \n> the past, such tagging would be very useful. Quite often I have been \n> looking through the Git log and wondered what feature a commit was \"part \n> of\", because I have feature branches. Just knowing that branch name \n> would be really useful, but the branch has since been deleted... and in \n> the case of a ff-merge (which I thought was recommended in Git if \n> possible), the branch name is completely gone.\n\nI still don't see why you would need that information, but if you really need\nit, you can write a commit hook that stores that information in the message,\nit's very trivial. Also, you can store that information in notes.\n\n> You can go back through the history and find \"Merge branch\n> 'pacman-minigame'\", but how do you know which commit was the *start* of that\n> branch, if they are not tagged with the branch name?\n\nBy recording the start of the branch.\n\n[1] https://github.com/felipec/git/commits/fc/tail\n\n-- \nFelipe Contreras\n"},{"id":"239845","messageId":"535E16D4.9040509@game-point.net","threadId":"36508","inReplyTo":"535DBD35.4080507@gmail.com","subject":"Re: Recording the current branch on each commit?","fromName":"Jeremy Morton","fromEmail":"admin@game-point.net","sentAt":"2014-04-28T08:52:36Z","receivedAt":"2014-04-28T08:52:36Z","isPatch":false,"sender":{"key":"admin@game-point.net","avatar":null},"body":"On 28/04/2014 03:30, Sitaram Chamarty wrote:\n> On 04/28/2014 01:03 AM, Johan Herland wrote:\n>> Yeah, sure. Author and Date (and Committer, for that matter) is just\n>> metadata, and the current branch name is simply just another kind of\n>> metadata. All of them are more-or-less free-form text fields, and off\n>\n> no they're not. In strictly controlled environments they form part of\n> the audit record for the source code.\n>\n> Yes they can be faked (explicitly), but -- again in strictly controlled\n> environments -- that can be limited to \"before it was first pushed\".\n\nWhy these specific headers as part of the audit record, though? Aren't \nyou just arbitrarily defining them as part of the audit record?\n\n-- \nBest regards,\nJeremy Morton (Jez)\n"},{"id":"239852","messageId":"535e1809bf54a_338911e930cb6@nysa.notmuch","threadId":"36508","inReplyTo":"CALKQrgemFx=2JaC1BaRqCwEV+knC8QftxcZ7K0AsT9azzuyVdA@mail.gmail.com","subject":"Re: Recording the current branch on each commit?","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-28T08:57:45Z","receivedAt":"2014-04-28T08:57:45Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Johan Herland wrote:\n> On Sun, Apr 27, 2014 at 7:38 PM, Jeremy Morton wrote:\n> > Whatsmore, tracking down which branch a commit pertains to is still rather\n> > difficult using this approach. You can go back through the history and\n> > find \"Merge branch 'pacman-minigame'\", but how do you know which commit was\n> > the *start* of that branch, if they are not tagged with the branch name?\n> \n> Once you have found the merge commit (M), git log M^1..M^2 should list\n> all the commits that were made on that branch. The parent of the last\n> in that list can be considered the starting point for the branch.\n\nIt's not that easy. There has been a lot of discussion in the mailing list and\nStackOverflow of ways to do this [1]. The conclusion, at least for me, is that\nthere's no way to find that out, so it has to be recorded.\n\n[1] http://thread.gmane.org/gmane.comp.version-control.git/198587\n\n-- \nFelipe Contreras\n"},{"id":"239855","messageId":"535e18cdc7bce_338911e930c72@nysa.notmuch","threadId":"36508","inReplyTo":"535D6EB1.9080208@game-point.net","subject":"Re: Recording the current branch on each commit?","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-28T09:01:01Z","receivedAt":"2014-04-28T09:01:01Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Jeremy Morton wrote:\n> On 27/04/2014 20:33, Johan Herland wrote:\n> > The problem is not really \"less tidy commit trees\" - by which I gather\n> > you mean history graphs that are non-linear. IMHO, the history graph\n> > should reflect parallel/branched development when that is useful.\n> > Blindly rebasing everything into a single line is IMHO just as bad as\n> > doing all your work directly on master and blindly running \"git pull\"\n> > between each of your own commits (which results in a lot of useless\n> > merges). The merge commits themselves are not the problem. Merge\n> > commits are a tool, and when used properly (to introduce topics to the\n> > master branch like described above) they are a good tool. When abused\n> > (like blindly running \"git pull\" and accepting useless \"merge\n> > bubbles\") they create more problems than they solve.\n> \n> Sounds like the default behaviour of \"git pull\" might not be ideal if it \n> easily causes these problems.\n\nIt's not idea. Virtually everyone agrees with that, even Linus Torvalds, and we\nhave the patches to fix it, but it's not going to change.\n\nThe Git project doesn't welcome change.\n\n-- \nFelipe Contreras\n"},{"id":"239848","messageId":"535E18E0.3010507@game-point.net","threadId":"36508","inReplyTo":"20140428.084543.1615507400056684596.chriscool@tuxfamily.org","subject":"Re: Recording the current branch on each commit?","fromName":"Jeremy Morton","fromEmail":"admin@game-point.net","sentAt":"2014-04-28T09:01:20Z","receivedAt":"2014-04-28T09:01:20Z","isPatch":false,"sender":{"key":"admin@game-point.net","avatar":null},"body":"On 28/04/2014 07:45, Christian Couder wrote:\n> Yes, it's possible. Yesterday, I sent the following patch:\n>\n> [RFC/PATCH 2/2] trailer: add examples to the documentation\n>\n> and it shows a commit-msg hook to do something like that:\n>\n> $ cat>.git/hooks/commit-msg< #!/bin/sh\n> git interpret-trailers --trim-empty --trailer \"git-version: \\$(git describe)\" \"\\$1\"> \"\\$1.new\"\n> mv \"\\$1.new\" \"\\$1\"\n> EOF\n> $ chmod +x .git/hooks/commit-msg\n>\n> I think you just need to use the following if you want the branch\n> instead of the git version:\n>\n> git interpret-trailers --trim-empty --trailer \"git-branch: \\$(git name-rev --name-only HEAD)\" \"\\$1\"> \"\\$1.new\"\n>\n> It could even be simpler if there was an option (which has already\n> been discussed) that made it possible to modify the file in\n> place. This way one would not need the 'mv \"\\$1.new\" \"\\$1\"' command.\n>\n> Best,\n> Christian.\n\nThis is certainly going in the right direction, but it's still \nimplemented as a hook on a per-repo basis. Do you foresee a point in \nthe future where these trailers could be added through simple one-liners \nin someone's global .gitconfig file? That's where I'd really like to \nget to.\n\n-- \nBest regards,\nJeremy Morton (Jez)\n"},{"id":"239850","messageId":"87r44h6d47.fsf@fencepost.gnu.org","threadId":"36508","inReplyTo":"535E1622.70608@game-point.net","subject":"Re: Recording the current branch on each commit?","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2014-04-28T09:02:16Z","receivedAt":"2014-04-28T09:02:16Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Jeremy Morton writes:\n\n> On 28/04/2014 09:32, Felipe Contreras wrote:\n>>>> some people to is to always merge with --no-ff, that way you see the branch\n>>>> name in the merge commit.\n>>>\n>>> But surely, it's recommended with Git that you try to avoid doing\n>>> --no-ff merges to avoid commit noise?\n>>\n>> Nope. Different people have different needs, there's no recommendation. If\n>> anything, the recommendation is to do a ff merge, because that's the default.\n>\n> That's what I'm saying. With an ff merge, you don't get the merge\n> commit message telling you the branch name.\n\nAnd I don't _want_ that branch name to be recorded. The whole point of\na distributed version control system is that it's nobody else's business\nhow I organize my work before submitting it.\n\nI don't want to have people tell me when submitting patches \"but can't\nyou give this a better branch name?\" and then have to use git\nfilter-branch or whatever else to get the branch name removed.\n\n> As I said before, I usually consider my branch names useful\n> information worth keeping around - I'm not sure why you don't.\n\nIt is _totally_ useless information in a distributed development model.\nWhy would or should anybody be concerned what private branches some\nsubmitter has developed his patches in?\n\nThis is not a useful part of a commit.\n\n-- \nDavid Kastrup\n"},{"id":"239853","messageId":"CALKQrgfN-bE7KpZFadtD806Xk29N_R2sYurPQSKHLSh0UwcZiw@mail.gmail.com","threadId":"36508","inReplyTo":"535E18E0.3010507@game-point.net","subject":"Re: Recording the current branch on each commit?","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2014-04-28T09:09:31Z","receivedAt":"2014-04-28T09:09:31Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Mon, Apr 28, 2014 at 11:01 AM, Jeremy Morton wrote:\n> On 28/04/2014 07:45, Christian Couder wrote:\n>> Yes, it's possible. Yesterday, I sent the following patch:\n>>\n>> [RFC/PATCH 2/2] trailer: add examples to the documentation\n>>\n>> and it shows a commit-msg hook to do something like that:\n>>\n>> $ cat>.git/hooks/commit-msg<> #!/bin/sh\n>> git interpret-trailers --trim-empty --trailer \"git-version: \\$(git\n>> describe)\" \"\\$1\"> \"\\$1.new\"\n>> mv \"\\$1.new\" \"\\$1\"\n>> EOF\n>> $ chmod +x .git/hooks/commit-msg\n>>\n>> I think you just need to use the following if you want the branch\n>> instead of the git version:\n>>\n>> git interpret-trailers --trim-empty --trailer \"git-branch: \\$(git name-rev\n>> --name-only HEAD)\" \"\\$1\"> \"\\$1.new\"\n>>\n>> It could even be simpler if there was an option (which has already\n>> been discussed) that made it possible to modify the file in\n>> place. This way one would not need the 'mv \"\\$1.new\" \"\\$1\"' command.\n>\n> This is certainly going in the right direction, but it's still implemented\n> as a hook on a per-repo basis. Do you foresee a point in the future where\n> these trailers could be added through simple one-liners in someone's global\n> .gitconfig file? That's where I'd really like to get to.\n\nIt's a hack, but it works surprisingly well in practice (assuming that\nyou and your co-workers all agree that this is an acceptable\napproach):\n\n 1. Write the hook script and add it to your project (in a git-hooks\nsubdir or something)\n\n 2. Add a post-checkout hook to install the first hook and the\npost-checkout hook itself into the user's .git/hooks/ dir.\n\n 3. Tell your co-workers to run the post-checkout hook script manually\nthe first time. After that, the script should take care of updating\nitself and any hooks that you add to the project.\n\n\n...Johan\n\n-- \nJohan Herland, \nwww.herland.net\n"},{"id":"239854","messageId":"535E1AF6.8080609@game-point.net","threadId":"36508","inReplyTo":"87r44h6d47.fsf@fencepost.gnu.org","subject":"Re: Recording the current branch on each commit?","fromName":"Jeremy Morton","fromEmail":"admin@game-point.net","sentAt":"2014-04-28T09:10:14Z","receivedAt":"2014-04-28T09:10:14Z","isPatch":false,"sender":{"key":"admin@game-point.net","avatar":null},"body":"On 28/04/2014 10:02, David Kastrup wrote:\n> Jeremy Morton writes:\n>\n>> On 28/04/2014 09:32, Felipe Contreras wrote:\n>>>>> some people to is to always merge with --no-ff, that way you see the branch\n>>>>> name in the merge commit.\n>>>>\n>>>> But surely, it's recommended with Git that you try to avoid doing\n>>>> --no-ff merges to avoid commit noise?\n>>>\n>>> Nope. Different people have different needs, there's no recommendation. If\n>>> anything, the recommendation is to do a ff merge, because that's the default.\n>>\n>> That's what I'm saying. With an ff merge, you don't get the merge\n>> commit message telling you the branch name.\n>\n> And I don't _want_ that branch name to be recorded. The whole point of\n> a distributed version control system is that it's nobody else's business\n> how I organize my work before submitting it.\n\nWell it would be optional, so obviously you wouldn't be forced to share \nthe branch name. It's not like we're trying to \"pry in\" to your private \ndevelopment. It's a way of choosing to share what you may consider to \nbe useful contextual information about the commit.\n\n> I don't want to have people tell me when submitting patches \"but can't\n> you give this a better branch name?\" and then have to use git\n> filter-branch or whatever else to get the branch name removed.\n>\n>> As I said before, I usually consider my branch names useful\n>> information worth keeping around - I'm not sure why you don't.\n>\n> It is _totally_ useless information in a distributed development model.\n> Why would or should anybody be concerned what private branches some\n> submitter has developed his patches in?\n\nWhy should anybody be concerned about what commit message some submitter \nhas typed in for his commit? They could just read the source code to \nsee what has changed, right?\n\nBecause the commit message is a way for the submitter to try and make it \neasier for the people looking at the commit to understand what the \ncommit is doing. In the same way, a meaningful branch name may also \nmake it easier for people looking at the commit to understand what it is \ndoing, or what part of the application it is affecting, or what group of \ncommits it is a part of.\n\n-- \nBest regards,\nJeremy Morton (Jez)\n"},{"id":"239856","messageId":"535E1C7A.3040504@game-point.net","threadId":"36508","inReplyTo":"CALKQrgfN-bE7KpZFadtD806Xk29N_R2sYurPQSKHLSh0UwcZiw@mail.gmail.com","subject":"Re: Recording the current branch on each commit?","fromName":"Jeremy Morton","fromEmail":"admin@game-point.net","sentAt":"2014-04-28T09:16:42Z","receivedAt":"2014-04-28T09:16:42Z","isPatch":false,"sender":{"key":"admin@game-point.net","avatar":null},"body":"On 28/04/2014 10:09, Johan Herland wrote:\n> On Mon, Apr 28, 2014 at 11:01 AM, Jeremy Morton wrote:\n>> On 28/04/2014 07:45, Christian Couder wrote:\n>>> Yes, it's possible. Yesterday, I sent the following patch:\n>>>\n>>> [RFC/PATCH 2/2] trailer: add examples to the documentation\n>>>\n>>> and it shows a commit-msg hook to do something like that:\n>>>\n>>> $ cat>.git/hooks/commit-msg<>> #!/bin/sh\n>>> git interpret-trailers --trim-empty --trailer \"git-version: \\$(git\n>>> describe)\" \"\\$1\"> \"\\$1.new\"\n>>> mv \"\\$1.new\" \"\\$1\"\n>>> EOF\n>>> $ chmod +x .git/hooks/commit-msg\n>>>\n>>> I think you just need to use the following if you want the branch\n>>> instead of the git version:\n>>>\n>>> git interpret-trailers --trim-empty --trailer \"git-branch: \\$(git name-rev\n>>> --name-only HEAD)\" \"\\$1\"> \"\\$1.new\"\n>>>\n>>> It could even be simpler if there was an option (which has already\n>>> been discussed) that made it possible to modify the file in\n>>> place. This way one would not need the 'mv \"\\$1.new\" \"\\$1\"' command.\n>>\n>> This is certainly going in the right direction, but it's still implemented\n>> as a hook on a per-repo basis. Do you foresee a point in the future where\n>> these trailers could be added through simple one-liners in someone's global\n>> .gitconfig file? That's where I'd really like to get to.\n>\n> It's a hack, but it works surprisingly well in practice (assuming that\n> you and your co-workers all agree that this is an acceptable\n> approach):\n>\n> 1. Write the hook script and add it to your project (in a git-hooks\n> subdir or something)\n>\n> 2. Add a post-checkout hook to install the first hook and the\n> post-checkout hook itself into the user's .git/hooks/ dir.\n>\n> 3. Tell your co-workers to run the post-checkout hook script manually\n> the first time. After that, the script should take care of updating\n> itself and any hooks that you add to the project.\n>\n>\n> ...Johan\n\nI don't understand why the co-workers need to run the post-checkout hook \nscript manually the first time?\n\n-- \nBest regards,\nJeremy Morton (Jez)\n"},{"id":"239858","messageId":"535e1ca4933da_338911e930c4@nysa.notmuch","threadId":"36508","inReplyTo":"535E1CAD.1020304@game-point.net","subject":"Re: Recording the current branch on each commit?","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-28T09:17:24Z","receivedAt":"2014-04-28T09:17:24Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Jeremy Morton wrote:\n> On 28/04/2014 10:01, Felipe Contreras wrote:\n> > Jeremy Morton wrote:\n> >> On 27/04/2014 20:33, Johan Herland wrote:\n> >>> The problem is not really \"less tidy commit trees\" - by which I gather\n> >>> you mean history graphs that are non-linear. IMHO, the history graph\n> >>> should reflect parallel/branched development when that is useful.\n> >>> Blindly rebasing everything into a single line is IMHO just as bad as\n> >>> doing all your work directly on master and blindly running \"git pull\"\n> >>> between each of your own commits (which results in a lot of useless\n> >>> merges). The merge commits themselves are not the problem. Merge\n> >>> commits are a tool, and when used properly (to introduce topics to the\n> >>> master branch like described above) they are a good tool. When abused\n> >>> (like blindly running \"git pull\" and accepting useless \"merge\n> >>> bubbles\") they create more problems than they solve.\n> >>\n> >> Sounds like the default behaviour of \"git pull\" might not be ideal if it\n> >> easily causes these problems.\n> >\n> > It's not idea. Virtually everyone agrees with that, even Linus Torvalds, and we\n> > have the patches to fix it, but it's not going to change.\n> >\n> > The Git project doesn't welcome change.\n> \n> Well, you sure don't seem to. Why are there so many \"no-can-do\" people \n> on this list? :-)\n\nI don't seem to what? I'm the one arguing for change, and I sent the patches to\nfix this default behavior.\n\n-- \nFelipe Contreras\n"},{"id":"239857","messageId":"535E1CAD.1020304@game-point.net","threadId":"36508","inReplyTo":"535e18cdc7bce_338911e930c72@nysa.notmuch","subject":"Re: Recording the current branch on each commit?","fromName":"Jeremy Morton","fromEmail":"admin@game-point.net","sentAt":"2014-04-28T09:17:33Z","receivedAt":"2014-04-28T09:17:33Z","isPatch":false,"sender":{"key":"admin@game-point.net","avatar":null},"body":"On 28/04/2014 10:01, Felipe Contreras wrote:\n> Jeremy Morton wrote:\n>> On 27/04/2014 20:33, Johan Herland wrote:\n>>> The problem is not really \"less tidy commit trees\" - by which I gather\n>>> you mean history graphs that are non-linear. IMHO, the history graph\n>>> should reflect parallel/branched development when that is useful.\n>>> Blindly rebasing everything into a single line is IMHO just as bad as\n>>> doing all your work directly on master and blindly running \"git pull\"\n>>> between each of your own commits (which results in a lot of useless\n>>> merges). The merge commits themselves are not the problem. Merge\n>>> commits are a tool, and when used properly (to introduce topics to the\n>>> master branch like described above) they are a good tool. When abused\n>>> (like blindly running \"git pull\" and accepting useless \"merge\n>>> bubbles\") they create more problems than they solve.\n>>\n>> Sounds like the default behaviour of \"git pull\" might not be ideal if it\n>> easily causes these problems.\n>\n> It's not idea. Virtually everyone agrees with that, even Linus Torvalds, and we\n> have the patches to fix it, but it's not going to change.\n>\n> The Git project doesn't welcome change.\n\nWell, you sure don't seem to. Why are there so many \"no-can-do\" people \non this list? :-)\n\n-- \nBest regards,\nJeremy Morton (Jez)\n"},{"id":"239902","messageId":"87fvkx6c4z.fsf@fencepost.gnu.org","threadId":"36508","inReplyTo":"535E1AF6.8080609@game-point.net","subject":"Re: Recording the current branch on each commit?","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2014-04-28T09:23:24Z","receivedAt":"2014-04-28T09:23:24Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Jeremy Morton writes:\n\n> On 28/04/2014 10:02, David Kastrup wrote:\n>> Jeremy Morton writes:\n>>\n>>> On 28/04/2014 09:32, Felipe Contreras wrote:\n>>>>>> some people to is to always merge with --no-ff, that way you see the branch\n>>>>>> name in the merge commit.\n>>>>>\n>>>>> But surely, it's recommended with Git that you try to avoid doing\n>>>>> --no-ff merges to avoid commit noise?\n>>>>\n>>>> Nope. Different people have different needs, there's no recommendation. If\n>>>> anything, the recommendation is to do a ff merge, because that's the default.\n>>>\n>>> That's what I'm saying. With an ff merge, you don't get the merge\n>>> commit message telling you the branch name.\n>>\n>> And I don't _want_ that branch name to be recorded. The whole point of\n>> a distributed version control system is that it's nobody else's business\n>> how I organize my work before submitting it.\n>\n> Well it would be optional, so obviously you wouldn't be forced to\n> share the branch name. It's not like we're trying to \"pry in\" to your\n> private development. It's a way of choosing to share what you may\n> consider to be useful contextual information about the commit.\n\nBut it isn't useful contextual information about the commit because it\nis tied to a particular repository.\n\n>> It is _totally_ useless information in a distributed development\n>> model. Why would or should anybody be concerned what private\n>> branches some submitter has developed his patches in?\n>\n> Why should anybody be concerned about what commit message some\n> submitter has typed in for his commit? They could just read the\n> source code to see what has changed, right?\n\nThe commit message is an integral part of a commit. The contents of the\ncommit message are not tied to a particular repository. The branch\nname, however, is.\n\n> Because the commit message is a way for the submitter to try and make\n> it easier for the people looking at the commit to understand what the\n> commit is doing.\n\nThe commit message is written for an audience and is independent of the\nrepository. The branch name isn't.\n\n> In the same way, a meaningful branch name may also make it easier for\n> people looking at the commit to understand what it is doing,\n\nIt is nobody's business how I name my branches. I can change the commit\nmessage using git commit --amend, but what should happen if I rename the\nbranch a commit is on?\n\nAnd what nightmare should occur when doing git cherry-pick? What _is_\nthe originating branch of a cherry-pick? What _is_ the originating\nbranch of a merge commit? Or even of a cherry-picked merge commit?\n\n> or what part of the application it is affecting, or what group of\n> commits it is a part of.\n\nIf I have useful information to offer to the readers of a commit, it\nbelongs in the commit message. Not in some involuntarily created and\nleaked piece of metadata specific to my workflow and repository that\nwill be awfully hard to change after the fact.\n\n-- \nDavid Kastrup\n"},{"id":"239859","messageId":"535E20DC.2040405@game-point.net","threadId":"36508","inReplyTo":"535e1ca4933da_338911e930c4@nysa.notmuch","subject":"Re: Recording the current branch on each commit?","fromName":"Jeremy Morton","fromEmail":"admin@game-point.net","sentAt":"2014-04-28T09:35:24Z","receivedAt":"2014-04-28T09:35:24Z","isPatch":false,"sender":{"key":"admin@game-point.net","avatar":null},"body":"On 28/04/2014 10:17, Felipe Contreras wrote:\n>\n> I don't seem to what? I'm the one arguing for change, and I sent the patches to\n> fix this default behavior.\n\nWell maybe you should work on phrasing things better - you come across \nas quite negative.\n\n-- \nBest regards,\nJeremy Morton (Jez)\n"},{"id":"239900","messageId":"87bnvl6bdg.fsf@fencepost.gnu.org","threadId":"36508","inReplyTo":"535e18cdc7bce_338911e930c72@nysa.notmuch","subject":"Re: Recording the current branch on each commit?","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2014-04-28T09:39:55Z","receivedAt":"2014-04-28T09:39:55Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Felipe Contreras writes:\n\n> Jeremy Morton wrote:\n>> \n>> Sounds like the default behaviour of \"git pull\" might not be ideal if\n>> it easily causes these problems.\n>\n> It's not idea. Virtually everyone agrees with that, even Linus\n> Torvalds, and we have the patches to fix it, but it's not going to\n> change.\n>\n> The Git project doesn't welcome change.\n\nI can think of a few other things that \"the Git project\" or actually\npretty much everybody doesn't welcome.\n\nIt becomes easier to actually change things when communicating in a less\nabrasive and destructive manner.\n\nAt any rate, releases involve time plans and testing periods.\nPersonally I think that the automerging behavior of \"git pull\" is one of\nthe most stupid traps Git has available for beginning contributors to\nmake a royal mess of their contributions. It's unbelievable that this\nhas not been defused a decade ago already.\n\nBut it hasn't, and such a change is no longer in a useful time frame for\na 2.0 release. Unless one wants to push back the 2.0 release\nconsiderably for this alone. But then everybody will have a favorite\npet peeve, some likely more justified, some less, that he wants to get\ninto 2.0. I mean, I just sped up git-blame for serious use cases by a\nfactor of 3 or so at least, and there will be _no_ API changes and\nuser-visible consequences with that change.\n\nSo what?\n\nIf the thing has been important enough to get into 2.0, it has been\nimportant enough to push for it _timely_ so that it had a chance at\nconsiderable testing exposure.\n\nThat's what has been done with the \"git push\" changes. They were put in\ntimely, with quite a bit of warning about what will change and what\npeople are supposed to be doing about it. Again: bad enough that it\ntook as long as that to fix this insanely reckless default. The scale\nof the git-pull problem is small in comparison as it only messes up a\nsingle local branch instead of a whole set of upstream branches.\n\n-- \nDavid Kastrup\n"},{"id":"239861","messageId":"535E276E.8090306@gmail.com","threadId":"36508","inReplyTo":"87zjj656my.fsf@fencepost.gnu.org","subject":"Re: Recording the current branch on each commit?","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2014-04-28T10:03:26Z","receivedAt":"2014-04-28T10:03:26Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"On 04/28/2014 11:37 AM, David Kastrup wrote:\n> Johan Herland writes:\n>\n>> Obviously, the feature would necessarily have to be optional, simply\n>> because Git would have to keep understanding the old commit object\n>> format for a LONG time (probably indefinitely), and there's nothing\n>> you can do to prevent others from creating old-style commit objects.\n\nJohan: I seem to have missed your previous email (fat-fingered something\non my mail client I expect).\n\nYour **reasons** for making it optional are all wrong. People like me\n(and David) who are opposed to this run the risk that if the **format**\nwere to officially change in some way or for some reason (like, say, if\nSHA1 is no longer in favour, or whatever), then this \"feature\" is\nfoisted on us willy-nilly.\n\nThat's not good.\n\nSo, while I appreciate your point that it should be optional, please\nlet's accept that in the end it should be optional because **not\neveryone likes it**!\n\n> Personally, I am _strongly_ opposed. How I name and juggle my private\n> branches is nobody else's business in a distributed version control\n> system.\n>\n> They are private. My personal workflow. Not part of a commit.\n\nHear hear!!\n"},{"id":"239862","messageId":"535E277C.9070502@gmail.com","threadId":"36508","inReplyTo":"535E16D4.9040509@game-point.net","subject":"Re: Recording the current branch on each commit?","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2014-04-28T10:03:40Z","receivedAt":"2014-04-28T10:03:40Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"On 04/28/2014 02:22 PM, Jeremy Morton wrote:\n> On 28/04/2014 03:30, Sitaram Chamarty wrote:\n>> On 04/28/2014 01:03 AM, Johan Herland wrote:\n>>> Yeah, sure. Author and Date (and Committer, for that matter) is just\n>>> metadata, and the current branch name is simply just another kind of\n>>> metadata. All of them are more-or-less free-form text fields, and off\n>>\n>> no they're not. In strictly controlled environments they form part of\n>> the audit record for the source code.\n>>\n>> Yes they can be faked (explicitly), but -- again in strictly controlled\n>> environments -- that can be limited to \"before it was first pushed\".\n>\n> Why these specific headers as part of the audit record, though?\n> Aren't you just arbitrarily defining them as part of the audit record?\n\n\"who did it\" and \"when did they do it\" are a fair bit more central to\n\"how did we get here\" (viz., the SHA1 of the top commit, if you will)\nthan \"what branch was this commit born in (or similar)\".\n\nHere's an example from somewhere I worked (indirectly) in the late 90s.\nNasty bug, easily fixable (a few characters to change). Customer group\nall p-ed off. Developer has access to the version control server. He\nchanges something on the VC system to appear as if the bug never existed\nin the version of the code he shipped to whoever. As a result, the bug\nwas deemed to have \"mysteriously\" appeared somewhere along the line. It\ndidn't help that parts of the workflow were semi-manual, so he *did*\nhave vague things to point at.\n\nI don't believe I can explain that any better or go into details without\nsome risk, so if you don't agree then that's all there is to it.\n\nSuffice it to say I am strongly opposed to the idea, but as long as it's\noptional -- and for the right reasons (see my other email) -- I'd be OK.\n"},{"id":"239975","messageId":"CALKQrgeFJf5RZTR7df1CeAAta1vdjDccj2Y+zXTfzCS9Zy9SYQ@mail.gmail.com","threadId":"36508","inReplyTo":"535E276E.8090306@gmail.com","subject":"Re: Recording the current branch on each commit?","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2014-04-28T16:38:35Z","receivedAt":"2014-04-28T16:38:35Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Mon, Apr 28, 2014 at 12:03 PM, Sitaram Chamarty wrote:\n>> Johan Herland writes:\n>>> Obviously, the feature would necessarily have to be optional, simply\n>>> because Git would have to keep understanding the old commit object\n>>> format for a LONG time (probably indefinitely), and there's nothing\n>>> you can do to prevent others from creating old-style commit objects.\n>\n> Johan: I seem to have missed your previous email (fat-fingered something\n> on my mail client I expect).\n>\n> Your **reasons** for making it optional are all wrong. People like me\n> (and David) who are opposed to this run the risk that if the **format**\n> were to officially change in some way or for some reason (like, say, if\n> SHA1 is no longer in favour, or whatever), then this \"feature\" is\n> foisted on us willy-nilly.\n>\n> That's not good.\n>\n> So, while I appreciate your point that it should be optional, please\n> let's accept that in the end it should be optional because **not\n> everyone likes it**!\n\nYou may have missed more than just one previous email... I tried (but\nobviously failed) to make it clear from the start that I personally\ndon't support this feature (although, as long as it's optional I'm\nmostly indifferent to it).\n\nTrying to steer the discussion towards a constructive end, I then\nargued that even IF we were to agree that this was a good change (and\nthis thread CLEARLY demonstrates that we DO NOT agree), it would STILL\nbe better to first implement this change within the confines of the\nexisting object model, without making any changes to Git itself.\n\nHaving done an initial implementation \"outside\" of the git core (which\nshould be fairly straightforward with hooks + git-interpret-trailers),\nJeremy would have gotten the feature he wanted (or at least a close\napproximation), and we could then observe if this feature became\npopular/useful enough to consider integrating it into core Git.\n\nSo, the only constructive way forward (whether we like the feature or\nnot) is for Jeremy (or someone else) to first implement it \"outside\"\nthe Git core.\n\nTHIS is my point, and I really, REALLY tried to explain it while\nAVOIDING the inevitable flamewar about what \"belongs\" in a commit\nobject or not. It's not that I don't have an opinion on that subject;\nit's that everybody has their own opinion, and it's largely a\nphilosophical discussion that boils down to peoples workflows,\npreferences, backgrounds, and whatnot. As such, it's perfect material\nfor the flamewar we're currently observing...\n\n\n...Johan\n\n-- \nJohan Herland, \nwww.herland.net\n"},{"id":"239981","messageId":"535e8b8fb1ab2_4565148331059@nysa.notmuch","threadId":"36508","inReplyTo":"535E20DC.2040405@game-point.net","subject":"Re: Recording the current branch on each commit?","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-28T17:10:39Z","receivedAt":"2014-04-28T17:10:39Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Jeremy Morton wrote:\n> On 28/04/2014 10:17, Felipe Contreras wrote:\n> >\n> > I don't seem to what? I'm the one arguing for change, and I sent the\n> > patches to fix this default behavior.\n> \n> Well maybe you should work on phrasing things better - you come across as\n> quite negative.\n\nWhat is the difference between a negative person and a realist, when what both\nsay are the same and true?\n\nIt's literally almost impossible to change an existing behavior in Git,\nincluding the default behavior of 'git pull`, even if basically everybody\nagrees the current behavior is wrong. That's just a fact.\n\n-- \nFelipe Contreras\n"},{"id":"239986","messageId":"535e8e4253196_45651483310b3@nysa.notmuch","threadId":"36508","inReplyTo":"87bnvl6bdg.fsf@fencepost.gnu.org","subject":"Re: Recording the current branch on each commit?","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-28T17:22:10Z","receivedAt":"2014-04-28T17:22:10Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"David Kastrup wrote:\n> Felipe Contreras writes:\n> \n> > Jeremy Morton wrote:\n> >> \n> >> Sounds like the default behaviour of \"git pull\" might not be ideal if\n> >> it easily causes these problems.\n> >\n> > It's not idea. Virtually everyone agrees with that, even Linus\n> > Torvalds, and we have the patches to fix it, but it's not going to\n> > change.\n> >\n> > The Git project doesn't welcome change.\n> \n> I can think of a few other things that \"the Git project\" or actually\n> pretty much everybody doesn't welcome.\n> \n> It becomes easier to actually change things when communicating in a less\n> abrasive and destructive manner.\n\nThat would make sense if I was the only one with the itch. But I wasn't the\nonly one, so anybody could take the patches and send them in a less abrasive\nmaner.\n\nIn fact I have been contacted a couple of times privately suggesting me to use\na softer tone in order to get my patches applied, in every time I issue a\nchallenge. You send the patches, and you follow up the discussion in whatever\ntone you see fit, if they get in, I'll accept I'm wrong and use softer tone in\nthe future. The fact of the matter is that the tone doesn't matter, the patches\ndon't get in because change is not welcome. Period.\n\n> But it hasn't, and such a change is no longer in a useful time frame for\n> a 2.0 release.\n\nI sent the last version of the series in Octoboer 2013, there was more than\nenough time to merge them, or somebody else with more political traction to\npick and finish whatever changes where needed (none).\n\n> Unless one wants to push back the 2.0 release considerably for this alone.\n\nWhy does it need to be pushed back? Have you looked at the patches? If so, what\nis the risk that there will be any problem with them?\n\n> I mean, I just sped up git-blame for serious use cases by a factor of 3 or so\n> at least, and there will be _no_ API changes and user-visible consequences\n> with that change.\n\nI bet this could get into 2.0, but the big patch has to be split into smaller\npatches in order for them to be reviewed properly, and maybe merge a few of\nthem at a time.\n\n> If the thing has been important enough to get into 2.0, it has been\n> important enough to push for it _timely_ so that it had a chance at\n> considerable testing exposure.\n\nReally? What important changes does 2.0 have? There's literally nothing of\ninterest to most users, maybe push.default = simple, but that's it.\n\n-- \nFelipe Contreras\n"},{"id":"239999","messageId":"xmqqeh0hs6n7.fsf@gitster.dls.corp.google.com","threadId":"36508","inReplyTo":"535D3DF8.4020904@game-point.net","subject":"Re: Recording the current branch on each commit?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-04-28T17:31:08Z","receivedAt":"2014-04-28T17:31:08Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeremy Morton writes:\n\n> But surely, it's recommended with Git that you try to avoid doing\n> --no-ff merges to avoid commit noise?\n\nThat is a misconception, I am afraid, coming from two different\ncamps.\n\nSome projects do not want any merges for whatever reason, not\nlimited to --no-ff merges. They want linear history perhaps due to\ninertia from their CVS days.\n\nIn mergy projects, where no such \"merge avesion\" exists, there still\nis a valid reason why you are told to avoid no-ff, but I do not\nthink it is primarily because no-ff is bad. The real reason why\npeople need no-ff to record the fact that the \"side branch\" was a\nseparate development is because they rebase on top of the project's\ntip right before they push it out. If you do not do that last\nminute rebase, you do not have to do a no-ff, unless the project is\nso quiet and no other people are actively working on the codebase.\nAnd in such a case, no-ff would be very much justified.\n\nI do not fundamentally oppose if you want to add \"Done-as-part-of:\nfrotz-topic\" at the end of the log message of each commit that\nbelongs to the topic in your project (I personally wouldn't welcome\nsuch a convention in _this_ project, though). Christian's\n\"trailers\" series may serve as a building block for such a feature.\n\nBut as we can see in the thread, many people view (including me)\nthat the choice of branch name is a personal thing, irrelevant in\nthe project-wide history, so even if you add a built-in support to\nmake it easier for you to add such a trailer, it has to be something\noptional the projects explicitly must choose to use by flipping some\ntoggle.\n"},{"id":"240085","messageId":"152626b3-0642-4e26-9333-7d911d45c669@email.android.com","threadId":"36508","inReplyTo":"535e8e4253196_45651483310b3@nysa.notmuch","subject":"Re: Recording the current branch on each commit?","fromName":"James Denholm","fromEmail":"nod.helm@gmail.com","sentAt":"2014-04-28T23:03:23Z","receivedAt":"2014-04-28T23:03:23Z","isPatch":false,"sender":{"key":"nod.helm@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1721189?v=4"},"body":"Felipe Contreras wrote:\n>David Kastrup wrote:\n>> It becomes easier to actually change things when communicating in a\n>less\n>> abrasive and destructive manner.\n>\n>That would make sense if I was the only one with the itch. But I wasn't\n>the\n>only one, so anybody could take the patches and send them in a less\n>abrasive\n>maner.\n\nIt's not anybody else's job to take your patches and drizzle them in the\nhoney of respectable discourse. They're your patches, nobody else is\ngoing to champion them for you.\n\n>The fact of the matter is that the tone doesn't matter, the patches\n>don't get in because change is not welcome. Period.\n\nYou neglect the possibility that your personal view of what git should\nbe differs from other people's. One's views and values aren't correct\njust on the virtue of that person having them, and you are no different,\nFelipe.\n"},{"id":"240087","messageId":"535edfb9baa4a_4c5c11c92f0bc@nysa.notmuch","threadId":"36508","inReplyTo":"152626b3-0642-4e26-9333-7d911d45c669@email.android.com","subject":"Re: Recording the current branch on each commit?","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-28T23:09:45Z","receivedAt":"2014-04-28T23:09:45Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"James Denholm wrote:\n> Felipe Contreras wrote:\n> > David Kastrup wrote:\n> > > It becomes easier to actually change things when communicating in a less\n> > > abrasive and destructive manner.\n> >\n> > That would make sense if I was the only one with the itch. But I wasn't the\n> > only one, so anybody could take the patches and send them in a less\n> > abrasive maner.\n> \n> It's not anybody else's job to take your patches and drizzle them in the\n> honey of respectable discourse.\n\nIt's nobody's job to do anything. This a collaborative effort and in a\ncollaborative effort everbody chimes in to do different things.\n\nIt's not Jeff's patches, they are our patches, they are part of the project.\nAnd it's not unusual for multiple people working on a patch series; one person\ndoing most of the work, another adding tests, another cleaning updocumentation.\nIt's also no unheard of from a person picking up a patch series somebody else\nstopped working on.\n\nIf a patch series is event considered to be merged upstream, that means it\ndoesn't just benefit the person sending it (e.g. me), it benefits all Git\nusers.\n\nSo \"my\" patches where by the project and for the project.\n\n> > The fact of the matter is that the tone doesn't matter, the patches don't\n> > get in because change is not welcome. Period.\n> \n> You neglect the possibility that your personal view of what git should\n> be differs from other people's.\n\nExcept that in this case virtually everyone agreed the default was wrong. I\nalready said that.\n\nClarly you didn't read the relevant discussions where everyone, including Linus\nTorvalds, agreed. Did you?\n\n-- \nFelipe Contreras\n"},{"id":"240091","messageId":"xmqqk3a9m3ah.fsf@gitster.dls.corp.google.com","threadId":"36508","inReplyTo":"535edfb9baa4a_4c5c11c92f0bc@nysa.notmuch","subject":"Re: Recording the current branch on each commit?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-04-28T23:40:06Z","receivedAt":"2014-04-28T23:40:06Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n> Except that in this case virtually everyone agreed the default was wrong. I\n> already said that.\n>\n> Clarly you didn't read the relevant discussions where everyone, including Linus\n> Torvalds, agreed. Did you?\n\nMy recollection is that everybody agreed that the default was\nwrong. I do not think I saw everybody agreed the patch you are\nchampioning is the right solution to solve that problem.\n"},{"id":"240093","messageId":"535ee95fc17d5_5a07e812f018@nysa.notmuch","threadId":"36508","inReplyTo":"xmqqk3a9m3ah.fsf@gitster.dls.corp.google.com","subject":"Re: Recording the current branch on each commit?","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-28T23:50:55Z","receivedAt":"2014-04-28T23:50:55Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n> Felipe Contreras writes:\n> \n> > Except that in this case virtually everyone agreed the default was wrong. I\n> > already said that.\n> >\n> > Clarly you didn't read the relevant discussions where everyone, including Linus\n> > Torvalds, agreed. Did you?\n> \n> My recollection is that everybody agreed that the default was\n> wrong. I do not think I saw everybody agreed the patch you are\n> championing is the right solution to solve that problem.\n\nI'm going to add the quote you removed:\n\n> > James Denholm wrote:\n> > > You neglect the possibility that your personal view of what git should be\n> > > differs from other people's.\n\nIn this context James was talking about what Git should be. But the vast\nmajority agree on this issue, so that's not what's preventing change.\n\n-- \nFelipe Contreras\n"},{"id":"240095","messageId":"xmqqfvkxm1wc.fsf@gitster.dls.corp.google.com","threadId":"36508","inReplyTo":"535ee95fc17d5_5a07e812f018@nysa.notmuch","subject":"Re: Recording the current branch on each commit?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-04-29T00:10:11Z","receivedAt":"2014-04-29T00:10:11Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n> In this context James was talking about what Git should be. But the vast\n> majority agree on this issue, so that's not what's preventing change.\n\nSorry, I saw \"take your patches\" from James and \"my patch\" from you\nin the context above that part, and somehow thought that the\ndiscussion was about the reason why a particular implementation that\nhit 'pu' once stalled and did not result in changing Git.\n\nI agree that recognition of the issue is not what prevents a change.\n"},{"id":"240099","messageId":"535ef965e15dd_5f0313212ec3d@nysa.notmuch","threadId":"36508","inReplyTo":"xmqqfvkxm1wc.fsf@gitster.dls.corp.google.com","subject":"Re: Recording the current branch on each commit?","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-29T00:59:17Z","receivedAt":"2014-04-29T00:59:17Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n> Felipe Contreras writes:\n> \n> > In this context James was talking about what Git should be. But the vast\n> > majority agree on this issue, so that's not what's preventing change.\n> \n> I agree that recognition of the issue is not what prevents a change.\n\nIt's not just recognition of the issue, the solution is agreed too: change the\ndefault. The specifics of exactly how might not be.\n\n-- \nFelipe Contreras\n"},{"id":"240100","messageId":"CAHYYfeGBLXGgK-cTQLEreFXJakp1jBE829=LrhmKR3MttBiw+A@mail.gmail.com","threadId":"36508","inReplyTo":"535edfb9baa4a_4c5c11c92f0bc@nysa.notmuch","subject":"Re: Recording the current branch on each commit?","fromName":"James Denholm","fromEmail":"nod.helm@gmail.com","sentAt":"2014-04-29T01:29:57Z","receivedAt":"2014-04-29T01:29:57Z","isPatch":false,"sender":{"key":"nod.helm@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1721189?v=4"},"body":"Felipe Contreras wrote:\n> James Denholm wrote:\n>> It's not anybody else's job to take your patches and drizzle them in the\n>> honey of respectable discourse.\n>\n> It's nobody's job to do anything. This a collaborative effort and in a\n> collaborative effort everbody chimes in to do different things.\n\nNo, true, but my point was more related to that it's ones own \"task\",\nperhaps being the better term than job, to debate the merits of one's\nown work when the merits are currently unknown to the rest of a\ncommunity.\n\n> It's not Jeff's patches, they are our patches, they are part of the project.\n> And it's not unusual for multiple people working on a patch series; oneperson\n> doing most of the work, another adding tests, another cleaning updocumentation.\n> It's also no unheard of from a person picking up a patch series somebody else\n> stopped working on.\n\nThis, of course, would be the _other_ case where a proposal's\nmerits are already known and accepted by the community. Different\nsituation.\n\nNote that I here specify a proposal's merits are known and accepted,\nrather than the issue at hand. I'd be very, very surprised if there was\neven a few cases in human history where a community was able to\ncollaboratively work, efficiently and successfully, on a proposal where\nthe merits were still hotly discussed (barring, of course, exploratory\nworks).\n\n> If a patch series is event considered to be merged upstream, that means it\n> doesn't just benefit the person sending it (e.g. me), it benefits all Git\n> users.\n>\n> So \"my\" patches where by the project and for the project.\n\nAnd yes, of course, but you misinterpret my use of \"one's patches\" to\ndescribe ownership or who benefits from those patches. I merely\ndiscuss authorship and seek not to imply anything more.\n\n>> > The fact of the matter is that the tone doesn't matter, the patches don't\n>> > get in because change is not welcome. Period.\n>>\n>> You neglect the possibility that your personal view of what git should\n>> be differs from other people's.\n>\n> Except that in this case virtually everyone agreed the default was wrong. I\n> already said that.\n>\n> Clarly you didn't read the relevant discussions where everyone, including Linus\n> Torvalds, agreed. Did you?\n\nI'm talking about the general case, not a _specific_ patch or set\nthereof authored by you or any one person.\n\nAgain, though, recall that even if a community has agreed that\nthe current state is non-ideal, that doesn't mean that they agree\nthat a _specific proposal_ is the right one. If A and B agree that\nthey are starving to death, and B proposes they engage in hunting\nto resolve this, A might disagree because he'd rather just go\nacross the street and buy a loaf of bread.\n\nAlthough as I write this it seems Junio has described this exact\nthing in a following mail, and on the following debate:\n\nA patch relates to more than a personal view of what a project\nshouldn't be. Even if it's solving an acknowledged problem, it\nby it's nature relates to a view of what the solution should be.\n\nErgo, in the specific case, your view of what the solution should\nhave been did not match the community's view of the same, even\nif the overall problem was acknowledged by the entire community.\n\nThe default may be wrong, you and I might agree that the default is\nwrong, Junio and Torvalds and RMS and The Queen of England\nmight all agree that the default is wrong... But if we all live across\nfrom a bread shop, it's going to be a difficult task for you to convince\nus to go hunting.\n\nSincerely and analogically yours,\nJames Denholm.\n"},{"id":"240111","messageId":"535f1d4d8cbbb_762310ef30c9c@nysa.notmuch","threadId":"36508","inReplyTo":"CAHYYfeGBLXGgK-cTQLEreFXJakp1jBE829=LrhmKR3MttBiw+A@mail.gmail.com","subject":"Re: Recording the current branch on each commit?","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-29T03:32:29Z","receivedAt":"2014-04-29T03:32:29Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"James Denholm wrote:\n> Felipe Contreras wrote:\n> > James Denholm wrote:\n> >> It's not anybody else's job to take your patches and drizzle them in the\n> >> honey of respectable discourse.\n> >\n> > It's nobody's job to do anything. This a collaborative effort and in a\n> > collaborative effort everbody chimes in to do different things.\n> \n> No, true, but my point was more related to that it's ones own \"task\",\n\nIt's still the same thing. Nobody gets assigned any tasks; people choose their\nown tasks, and they might choose tasks that other people were doing.\n\n> > It's not Jeff's patches, they are our patches, they are part of the project.\n> > And it's not unusual for multiple people working on a patch series; oneperson\n> > doing most of the work, another adding tests, another cleaning updocumentation.\n> > It's also no unheard of from a person picking up a patch series somebody else\n> > stopped working on.\n> \n> This, of course, would be the _other_ case where a proposal's\n> merits are already known and accepted by the community.\n\nNo. John might have sent a patch series X, and maybe he didn't explain\ncorrectly how it would benefit the project. Later on Mark finds out how those\npatches would be useful for himself and takes upon himself to get them merged,\nso he cleans them up and send an updated version with a clear explanation of\nhow they would be useful.\n\nIt's still the same proposal X, but a different person and a different strategy\nto get them merged.\n\nIn other words, the fact that the community has not yet accepted the merits of\nan approach doesn't mean that another person cannot champion it.\n\n> The default may be wrong, you and I might agree that the default is\n> wrong, Junio and Torvalds and RMS and The Queen of England\n> might all agree that the default is wrong... But if we all live across\n> from a bread shop, it's going to be a difficult task for you to convince\n> us to go hunting.\n\nIt doesn't matter if you want to go hunting and I want to buy bread, either one\nof those is better than starving to death.\n\nIn the Git project though, we choose to starve to death. Neither were my\npatches picked, nor did anybody else step up with a different proposal, we just\ndid nothing, which is what we always do.\n\n-- \nFelipe Contreras\n"},{"id":"240117","messageId":"220967ee-98a9-4731-88c0-43a9cba7220a@email.android.com","threadId":"36508","inReplyTo":"535f1d4d8cbbb_762310ef30c9c@nysa.notmuch","subject":"Re: Recording the current branch on each commit?","fromName":"James Denholm","fromEmail":"nod.helm@gmail.com","sentAt":"2014-04-29T06:53:10Z","receivedAt":"2014-04-29T06:53:10Z","isPatch":false,"sender":{"key":"nod.helm@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1721189?v=4"},"body":"On 29 April 2014 13:32:29 GMT+10:00, Felipe Contreras wrote:\n>James Denholm wrote:\n>> No, true, but my point was more related to that it's ones own \"task\",\n>> perhaps being the better term than job, to debate the merits of one's\n>>own work when the merits are currently unknown to the rest of a\n>>community.\n>\n>It's still the same thing. Nobody gets assigned any tasks; people\n>choose their\n>own tasks, and they might choose tasks that other people were doing.\n\nRight. Instead of bashing about in the haberdashery of\nmisinterpretation, allow me to explicitly restate my original\npoint.\n\nYou cannot expect that anybody but yourself is willing to propose,\ndebate the merits of and otherwise defend patches that you\nhave authored (herein \"your patches\", implying \nauthorship, not ownership).\n\nSome people *may*, but if they do not or do not successfully,\nthat does not imply the stagnation of the project.\n\nUltimately, the only person who can ensure that a patch is\nchampioned, and the only person who need feel a\nresponsibility to, is the author, and that responsibility\nis only ever to themselves.\n\nTL,DR: Champion your own patches, don't ask others to.\n\n>> > It's not Jeff's patches, they are our patches, they are part of the\n>project.\n>> > And it's not unusual for multiple people working on a patch series;\n>oneperson\n>> > doing most of the work, another adding tests, another cleaning\n>updocumentation.\n>> > It's also no unheard of from a person picking up a patch series\n>somebody else\n>> > stopped working on.\n>> \n>> This, of course, would be the _other_ case where a proposal's\n>> merits are already known and accepted by the community.\n>\n>No. John might have sent a patch series X, and maybe he didn't explain\n>correctly how it would benefit the project. Later on Mark finds out how\n>those\n>patches would be useful for himself and takes upon himself to get them\n>merged,\n>so he cleans them up and send an updated version with a clear\n>explanation of\n>how they would be useful.\n>\n>It's still the same proposal X, but a different person and a different\n>strategy\n>to get them merged.\n>\n>In other words, the fact that the community has not yet accepted the\n>merits of\n>an approach doesn't mean that another person cannot champion it.\n\nAs addressed above.\n\n>> The default may be wrong, you and I might agree that the default is\n>> wrong, Junio and Torvalds and RMS and The Queen of England\n>> might all agree that the default is wrong... But if we all live\n>across\n>> from a bread shop, it's going to be a difficult task for you to\n>convince\n>> us to go hunting.\n>\n>It doesn't matter if you want to go hunting and I want to buy bread,\n>either one\n>of those is better than starving to death.\n>\n>In the Git project though, we choose to starve to death. Neither were\n>my\n>patches picked, nor did anybody else step up with a different proposal,\n>we just\n>did nothing, which is what we always do.\n\nNot at all. Hunting may necessitate a negative side\neffect, such as betraying vegetarianism, having to go out\ninto the jungle for five days, risk life and limb, and (worse\nyet) sleep in a tent. This is an especially poor decision if we\nhonestly would prefer a loaf of bread, and we just need to find\na way across the street.\n\nAnd again, I'm referring to the general case here, but of your\nviews of what the solution should be clash with what the\ncommunity view is, you're not going to be able to convince\nthe community to go hunting. To tie in with the above, you\nsure aren't going to be able to if you don't engage in logical,\ncalm, reasonable discourse.\n\nRegards,\nJames.\n"},{"id":"240125","messageId":"535f62c1e740a_45e485b30887@nysa.notmuch","threadId":"36508","inReplyTo":"220967ee-98a9-4731-88c0-43a9cba7220a@email.android.com","subject":"Re: Recording the current branch on each commit?","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-29T08:28:49Z","receivedAt":"2014-04-29T08:28:49Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"James Denholm wrote:\n\n> You cannot expect that anybody but yourself is willing to propose,\n> debate the merits of and otherwise defend patches that you have\n> authored (herein \"your patches\", implying authorship, not\n> ownership).\n\nThis is the original comment:\n\n> David Kastrup wrote:\n> > It becomes easier to actually change things when communicating in\n> > a less abrasive and destructive manner.\n\nWhich is demonstrably false, as I already explained nobody else could\nget these patches in, regarldless of the abrasiveness, or lack\nthereof.\n\nMy point was that my abrasiveness is not an excuse not to do the\nchanges, as somebody else could get them in (or a similar proposal).\nBut they couldn't, because it's a change.\n\nYour point about me not expecting somebody else to defend my patches\nis irrelevant; it doesn't have anything to do with the topic, and it's\nnot relevant in general either.\n\nI didn't ask or expect anybody to defend my patches, my point was that\nDavid Kastrup was wrong; it wouldn't be easier to change things;\nbecause change is simply not welcome.\n\n> Ultimately, the only person who can ensure that a patch is\n> championed, and the only person who need feel a responsibility to,\n> is the author, and that responsibility is only ever to themselves.\n\nContributors don't have any responsibility to champion their patches.\nIt is pro bono work.\n\nI should champion my patches because I want to improve Git, not\nbecause I have a responsibility. And nobody else has any\nresponsibility either, but if somebody else want to improve Git as\nwell, they should chamption the patches (or others of their own) as\nwell.\n\nIn the meantime the problem still remains.\n\n> > It doesn't matter if you want to go hunting and I want to buy\n> > bread, either one of those is better than starving to death.\n> \n> Not at all. Hunting may necessitate a negative side effect, such as\n> betraying vegetarianism, having to go out into the jungle for five\n> days, risk life and limb, and (worse yet) sleep in a tent. This is\n> an especially poor decision if we honestly would prefer a loaf of\n> bread, and we just need to find a way across the street.\n\nYou obviously didn't read what I said.\n\n> And again, I'm referring to the general case here, but of your\n> views of what the solution should be clash with what the\n> community view is, you're not going to be able to convince\n> the community to go hunting.\n\nI'm not going to convince them to buy bread either.\n\nThe community wants to starve to death, and you couldn't convince them\notherwise either.\n\n-- \nFelipe Contreras\n"},{"id":"240124","messageId":"1473502218.1282188.1398760496823.JavaMail.zimbra@dewire.com","threadId":"36508","inReplyTo":"535f1d4d8cbbb_762310ef30c9c@nysa.notmuch","subject":"Re: Recording the current branch on each commit?","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg@dewire.com","sentAt":"2014-04-29T08:34:56Z","receivedAt":"2014-04-29T08:34:56Z","isPatch":false,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"\n\n----- Ursprungligt meddelande -----\n> Från: \"Felipe Contreras\" \n> Till: \"James Denholm\" , \"Felipe Contreras\" \n> Kopia: \"David Kastrup\" , \"Jeremy Morton\" , \"Johan Herland\" ,\n> \"Git mailing list\" \n> Skickat: tisdag, 29 apr 2014 5:32:29\n> Ämne: Re: Recording the current branch on each commit?\n> \n> James Denholm wrote:\n> > Felipe Contreras wrote:\n> > > James Denholm wrote:\n> > >> It's not anybody else's job to take your patches and drizzle them in the\n> > >> honey of respectable discourse.\n> > >\n> > > It's nobody's job to do anything. This a collaborative effort and in a\n> > > collaborative effort everbody chimes in to do different things.\n[...]\n\n> In the Git project though, we choose to starve to death. Neither were my\n> patches picked, nor did anybody else step up with a different proposal, we\n> just\n> did nothing, which is what we always do.\n\nJust because you are starving, the others may not be. I'll skip dinner today.\n\nNot all people view the world the same way you do. Sometimes they don't \"see it\" \nbecause they don't share your experience. A year later other people may have come to the\nsame conclusion as you (or not) and whatever the idea you had may come\nfrom someone else, when the world is ready. \n\nWhining won't help, it will just reduce your credibility, perhaps to the point\nthat people won't even read a improved proposal if you come up with one.\n\nRemember this is a high volume list, so you don't get much time to explain an idea. It's\na matter of karma.\n\n-- robin\n"},{"id":"240126","messageId":"87r44g33z4.fsf@fencepost.gnu.org","threadId":"36508","inReplyTo":"535f62c1e740a_45e485b30887@nysa.notmuch","subject":"Re: Recording the current branch on each commit?","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2014-04-29T09:00:15Z","receivedAt":"2014-04-29T09:00:15Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Felipe Contreras writes:\n\n> Contributors don't have any responsibility to champion their patches.\n> It is pro bono work.\n\nNo, that's just the appearance that should be upheld in the higher\nsociety. It's ok to get paid for work on Git as long as you don't\nmention it in public. It's also ok to get paid for _promises_ of work\nif you can make people believe you. Open Source is not much different\nfrom how politics and society in general work in the U.S.A. To get the\nreal wads of money, you first need to get the means not to have to talk\nabout money (it's ok if you do it by means totally opposed to \"the\npolitical cause\" as long as you don't talk about it), then you have to\nprefinance people's trust in you not being there for the money, and then\nyou are in a position to get paid for your work.\n\nAnyway, I digress. Even without all that not so \"pro bono\" background\nto \"pro bono work\", there is still a difference between \"pro bono\" work\nending up in the wastebin and \"pro bono\" work ending up in a product.\n\nEven while the ones getting the benefits from your work will not feel an\nobligation to make it worth your while, there is a difference in\nsatisfaction between getting your work trashed and getting it used.\n\nThe satisfaction by exploding in self-righteousness tends to be a poor\nsubstitute and is comparatively short-lived.\n\nYes, it may mean that you have to carry your child the last yards rather\nthan shout it across the finishing line. Even though it should have\nlegs perfectly suited to get it across the track on its own.\n\nOnly that way you get to pat it on its head.\n\n-- \nDavid Kastrup\n"},{"id":"240151","messageId":"535f702352d21_3aee3b2f0b9@nysa.notmuch","threadId":"36508","inReplyTo":"87r44g33z4.fsf@fencepost.gnu.org","subject":"Re: Recording the current branch on each commit?","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-29T09:25:55Z","receivedAt":"2014-04-29T09:25:55Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"David Kastrup wrote:\n> Felipe Contreras writes:\n> \n> > Contributors don't have any responsibility to champion their\n> > patches. It is pro bono work.\n> \n> No, that's just the appearance that should be upheld in the higher\n> society. It's ok to get paid for work on Git as long as you don't\n> mention it in public.\n\nThe word \"contribute\" implies doing something that was not necessary.\nIf somebody is paying you to do something, then it's not a\ncontribution, it is simply your duty.\n\nThat's why I used the word \"contributors\", to separate the people that\ndon't have a responsability, and the ones that do.\n\n> Even while the ones getting the benefits from your work will not\n> feel an obligation to make it worth your while, there is a\n> difference in satisfaction between getting your work trashed and\n> getting it used.\n\nI don't know why this keeps poping up in the thread, but it is\nstarting to seem to me that you are under the impression that I'm\nsomehow unable to get my patches merged.\n\nLook at the list of contributors of the past year, see who is #2:\n\nhttps://www.ohloh.net/p/git/contributors?query=&sort=commits_12_mo\n\nI know what kind of patches can get in, and what patches can't (the\nones that do any kind of relevant change). I know that from\nexperience.\n\n-- \nFelipe Contreras\n"},{"id":"240152","messageId":"87mwf431t3.fsf@fencepost.gnu.org","threadId":"36508","inReplyTo":"535f702352d21_3aee3b2f0b9@nysa.notmuch","subject":"Re: Recording the current branch on each commit?","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2014-04-29T09:47:04Z","receivedAt":"2014-04-29T09:47:04Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Felipe Contreras writes:\n\n> David Kastrup wrote:\n>\n>> Even while the ones getting the benefits from your work will not\n>> feel an obligation to make it worth your while, there is a\n>> difference in satisfaction between getting your work trashed and\n>> getting it used.\n>\n> I don't know why this keeps poping up in the thread, but it is\n> starting to seem to me that you are under the impression that I'm\n> somehow unable to get my patches merged.\n>\n> Look at the list of contributors of the past year, see who is #2:\n>\n> https://www.ohloh.net/p/git/contributors?query=&sort=commits_12_mo\n>\n> I know what kind of patches can get in, and what patches can't (the\n> ones that do any kind of relevant change). I know that from\n> experience.\n\nWell, there you have it. The ones that do any kind of relevant change\nare the ones that need thinking about and consideration. And when you\nare so verbose about them that\n\na) you are getting on people's nerves\nb) nobody else finds something worth saying that you did not already say\n\nthen the net effect is that it feels to the person in question he's\nmainly doing you (and not all that many others) a favor by investing the\nwork for properly considering it and its consequences.\n\nWhich is not much of an incentive. At any rate, we are in a phase\nsupposed to be shortly before the release of 2.0. So it is actually\nquite by design that patches doing any kind of relevant changes are not\ncurrently going through. You can be as nice or ugly about it as you\nwant right now and it will not affect 2.0 any more.\n\nBut it might do so regarding 2.1.\n\n-- \nDavid Kastrup\n"},{"id":"240153","messageId":"535f76db38a34_6f23159b31099@nysa.notmuch","threadId":"36508","inReplyTo":"87mwf431t3.fsf@fencepost.gnu.org","subject":"Re: Recording the current branch on each commit?","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-29T09:54:35Z","receivedAt":"2014-04-29T09:54:35Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"David Kastrup wrote:\n> Felipe Contreras writes:\n> \n> > David Kastrup wrote:\n> >\n> >> Even while the ones getting the benefits from your work will not\n> >> feel an obligation to make it worth your while, there is a\n> >> difference in satisfaction between getting your work trashed and\n> >> getting it used.\n> >\n> > I don't know why this keeps poping up in the thread, but it is\n> > starting to seem to me that you are under the impression that I'm\n> > somehow unable to get my patches merged.\n> >\n> > Look at the list of contributors of the past year, see who is #2:\n> >\n> > https://www.ohloh.net/p/git/contributors?query=&sort=commits_12_mo\n> >\n> > I know what kind of patches can get in, and what patches can't (the\n> > ones that do any kind of relevant change). I know that from\n> > experience.\n> \n> Well, there you have it. The ones that do any kind of relevant change\n> are the ones that need thinking about and consideration. And when you\n> are so verbose about them that\n> \n> a) you are getting on people's nerves\n> b) nobody else finds something worth saying that you did not already say\n> \n> then the net effect is that it feels to the person in question he's\n> mainly doing you (and not all that many others) a favor by investing the\n> work for properly considering it and its consequences.\n\nThis is the last time I say it: this is demonstrably false.\n\nYou claim that relevant changes can be made if the submitter is not so verbose\n(and less aggressive and what not).\n\nThis is obviously not the case. Show me any change of importance done in the\nlast two years, hell, make it four. And by change I mean something that was one\nway before, and was another way after.\n\nThere is nothing. It doesn't matter how these changes are presented. Changes\nare not welcome, doesn't matter who is championing them, or how. Period.\n\n> At any rate, we are in a phase supposed to be shortly before the release of\n> 2.0.\n\nThis is a red herring. All the patches I'm talking about were sent well before\n2.0 was imminent, six months to one year ago.\n\nEven more, I'm challenging you to find an important change since even four years\nago. You won't find any.\n\n> But it might do so regarding 2.1.\n\nNo, it won't. Neither 3.0.\n\n-- \nFelipe Contreras\n"},{"id":"240154","messageId":"87eh0g30it.fsf@fencepost.gnu.org","threadId":"36508","inReplyTo":"535f76db38a34_6f23159b31099@nysa.notmuch","subject":"Re: Recording the current branch on each commit?","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2014-04-29T10:14:50Z","receivedAt":"2014-04-29T10:14:50Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Felipe Contreras writes:\n\n> David Kastrup wrote:\n>\n>> Well, there you have it. The ones that do any kind of relevant change\n>> are the ones that need thinking about and consideration. And when you\n>> are so verbose about them that\n>> \n>> a) you are getting on people's nerves\n>> b) nobody else finds something worth saying that you did not already say\n>> \n>> then the net effect is that it feels to the person in question he's\n>> mainly doing you (and not all that many others) a favor by investing\n>> the work for properly considering it and its consequences.\n>\n> This is the last time I say it: this is demonstrably false.\n\nFeelings are not categorizable as \"demonstrably false\".\n\n> You claim that relevant changes can be made if the submitter is not so\n> verbose (and less aggressive and what not).\n>\n> This is obviously not the case. Show me any change of importance done\n> in the last two years, hell, make it four. And by change I mean\n> something that was one way before, and was another way after.\n\nThe default behavior of \"git push\". Colorized diffs. \"git add dir/\"\ncan now remove files. \"git gc --aggressive\" has been sanitized.\n\n-- \nDavid Kastrup\n"},{"id":"240156","messageId":"535f7c35cb5b1_7c7c10e32f019@nysa.notmuch","threadId":"36508","inReplyTo":"87eh0g30it.fsf@fencepost.gnu.org","subject":"Re: Recording the current branch on each commit?","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-29T10:17:25Z","receivedAt":"2014-04-29T10:17:25Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"David Kastrup wrote:\n> Felipe Contreras writes:\n> \n> > David Kastrup wrote:\n> >\n> >> Well, there you have it. The ones that do any kind of relevant change\n> >> are the ones that need thinking about and consideration. And when you\n> >> are so verbose about them that\n> >> \n> >> a) you are getting on people's nerves\n> >> b) nobody else finds something worth saying that you did not already say\n> >> \n> >> then the net effect is that it feels to the person in question he's\n> >> mainly doing you (and not all that many others) a favor by investing\n> >> the work for properly considering it and its consequences.\n> >\n> > This is the last time I say it: this is demonstrably false.\n> \n> Feelings are not categorizable as \"demonstrably false\".\n\nIt's demonsrable by the challenge below.\n\n> > You claim that relevant changes can be made if the submitter is not so\n> > verbose (and less aggressive and what not).\n> >\n> > This is obviously not the case. Show me any change of importance done\n> > in the last two years, hell, make it four. And by change I mean\n> > something that was one way before, and was another way after.\n> \n> The default behavior of \"git push\".\n\nThis is a minor change that not many people would notice, and it has not\nactually happend. But fine, let's count it as one.\n\n> Colorized diffs.\n\nThat's not a change.\n\n> \"git add dir/\"\n\nThat doesn't count as an important change.\n\n> can now remove files.\n\nIrrelevant.\n\n> \"git gc --aggressive\" has been sanitized.\n\nIrrelevant. Nobody did notice.\n\n\nThat's all you could list for *four* years? None of that would even be noticed\nby most of our users, maybe push.default (when it actually happens), but that's\n*one*.\n\n*One* important change in *four* years.\n\nThat's demonstration that change just does not happen. And if you disagree,\nthen we'll agree to disagree.\n\n-- \nFelipe Contreras\n"},{"id":"240157","messageId":"87a9b42zh8.fsf@fencepost.gnu.org","threadId":"36508","inReplyTo":"535f7c35cb5b1_7c7c10e32f019@nysa.notmuch","subject":"Re: Recording the current branch on each commit?","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2014-04-29T10:37:23Z","receivedAt":"2014-04-29T10:37:23Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Felipe Contreras writes:\n\n> David Kastrup wrote:\n>\n>> The default behavior of \"git push\".\n>\n> This is a minor change that not many people would notice, and it has not\n> actually happend. But fine, let's count it as one.\n\nShrug. Your diatribe is to a good part about the default behavior of\n\"git pull\". The \"minor\" change affects multiple branches in upstream,\nwhile your \"important change\" affects a single local branch.\n\nWith that sort of bias, it's easy to convince yourself of anything.\n\n-- \nDavid Kastrup\n"},{"id":"240159","messageId":"752e9542-7450-4928-a9cb-79b9c3b69bcd@email.android.com","threadId":"36508","inReplyTo":"535f7c35cb5b1_7c7c10e32f019@nysa.notmuch","subject":"Re: Recording the current branch on each commit?","fromName":"James Denholm","fromEmail":"nod.helm@gmail.com","sentAt":"2014-04-29T10:59:07Z","receivedAt":"2014-04-29T10:59:07Z","isPatch":false,"sender":{"key":"nod.helm@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1721189?v=4"},"body":"I've no right to say this, given that I've no contributions\nthus far to the project, little history in open source at all,\nand have only been following the list for less than a week,\nbut I'll say it anyway, mayhaps.\n\nAnd I don't mean this to cause offence, or inspire outrage,\nor any similar sort of thing. I mean this only with good\nintentions.\n\nBut Felipe, if you honestly feel that git has stagnated, and\nthat your contributions aren't wanted because we'd\nrather starve, then perhaps git isn't the right project for you.\n\nI'm not saying that you shouldn't work on the git codebase,\nyou could very easily fork it and make the innovative SCMS\nnone of us can see, and kill git. Can be done, if hunting really\nis the best choice as you say.\n"},{"id":"240169","messageId":"535f911fac157_2719108f3083a@nysa.notmuch","threadId":"36508","inReplyTo":"87a9b42zh8.fsf@fencepost.gnu.org","subject":"Re: Recording the current branch on each commit?","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-29T11:46:39Z","receivedAt":"2014-04-29T11:46:39Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"David Kastrup wrote:\n> Felipe Contreras writes:\n> \n> > David Kastrup wrote:\n> >\n> >> The default behavior of \"git push\".\n> >\n> > This is a minor change that not many people would notice, and it has not\n> > actually happend. But fine, let's count it as one.\n> \n> Shrug. Your diatribe is to a good part about the default behavior of\n> \"git pull\".\n\n> The \"minor\" change affects multiple branches in upstream,\n\nThis is what most people see by default since two years ago:\n\n warning: push.default is unset; its implicit value is changing in\n Git 2.0 from 'matching' to 'simple'. To squelch this message\n and maintain the current behavior after the default changes, use:\n\n git config --global push.default matching\n\n To squelch this message and adopt the new behavior now, use:\n\n git config --global push.default simple\n\n When push.default is set to 'matching', git will push local branches\n to the remote branches that already exist with the same name.\n\n In Git 2.0, Git will default to the more conservative 'simple'\n behavior, which only pushes the current branch to the corresponding\n remote branch that 'git pull' uses to update the current branch.\n\n See 'git help config' and search for 'push.default' for further information.\n (the 'simple' mode was introduced in Git 1.7.11. Use the similar mode\n 'current' instead of 'simple' if you sometimes use older versions of Git)\n\nDo you honestly believe that there's *anybody* out there is OK with seeing this\nmessage _every_ _single_ _time_ he pushes? No. Everybody has already configured\npush.default to one thing or the other. They won't see the change when 2.0 is\nreleased.\n\nAnd no, if by some miracle somebody hasn't configured that, it still won't\naffect the branches upstream, if anything changes is that the `git pull` will\nerror out warning the user that the upstream branch doesn't have the same name.\nIt won't affect the branches you actually push.\n\n> while your \"important change\" affects a single local branch.\n\nMy change does actually affect upstream branches, more than that, it affects\nthe upstream topology, because Git newcomers make merges by mistake when they\ncall `git pull` without knowing what the hell is going on. Everybody knows\nthat.\n\nAnd this is a red herring. I never said my change was important, we are talking\nabout the changes that have actually happened in the last four years, which is\nnone.\n\n> With that sort of bias, it's easy to convince yourself of anything.\n\nI'm done discussing with you. I already demonstrated that your claim is wrong.\nChange just doesn't happen.\n\n-- \nFelipe Contreras\n"},{"id":"240170","messageId":"535f915e3ed89_2719108f30817@nysa.notmuch","threadId":"36508","inReplyTo":"752e9542-7450-4928-a9cb-79b9c3b69bcd@email.android.com","subject":"Re: Recording the current branch on each commit?","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-29T11:47:42Z","receivedAt":"2014-04-29T11:47:42Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"James Denholm wrote:\n> I've no right to say this, given that I've no contributions I'm not\n> saying that you shouldn't work on the git codebase, you could very\n> easily fork it and make the innovative SCMS none of us can see, and\n> kill git. Can be done, if hunting really is the best choice as you\n> say.\n\nI already made a fork:\n\nhttp://felipec.wordpress.com/2013/10/28/git-fc/\n\n-- \nFelipe Contreras\n"},{"id":"240172","messageId":"514ff3d6-aea5-4b1d-8ff4-14e779876fb1@email.android.com","threadId":"36508","inReplyTo":"535f915e3ed89_2719108f30817@nysa.notmuch","subject":"Re: Recording the current branch on each commit?","fromName":"James Denholm","fromEmail":"nod.helm@gmail.com","sentAt":"2014-04-29T12:25:46Z","receivedAt":"2014-04-29T12:25:46Z","isPatch":false,"sender":{"key":"nod.helm@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1721189?v=4"},"body":"On 29 April 2014 21:47:42 GMT+10:00, Felipe Contreras wrote:\n>James Denholm wrote:\n>> I've no right to say this, given that I've no contributions I'm not\n>> saying that you shouldn't work on the git codebase, you could very\n>> easily fork it and make the innovative SCMS none of us can see, and\n>> kill git. Can be done, if hunting really is the best choice as you\n>> say.\n>\n>I already made a fork:\n>\n>http://felipec.wordpress.com/2013/10/28/git-fc/\n\nSweet. So now you're going to get open source journalism\ninterested in git-fc and gain a groundswell of support, right?\nSo that we can all have egg on our faces when it takes off\nand is proven superior... Right?\n"},{"id":"240177","messageId":"535fa9b15a495_6d5dff2f0e0@nysa.notmuch","threadId":"36508","inReplyTo":"514ff3d6-aea5-4b1d-8ff4-14e779876fb1@email.android.com","subject":"Re: Recording the current branch on each commit?","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-29T13:31:29Z","receivedAt":"2014-04-29T13:31:29Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"James Denholm wrote:\n> So that we can all have egg on our faces when it takes off and is\n> proven superior... Right?\n\nI don't know what you mean by \"we\", but it certainly doesn't include\nyou.\n\n % git log --author=nod.helm@gmail.com master\n empty\n\n-- \nFelipe Contreras\n"},{"id":"240202","messageId":"e31d0160-c7e1-4e80-93bb-d1da590eb8b5@email.android.com","threadId":"36508","inReplyTo":"535fa9b15a495_6d5dff2f0e0@nysa.notmuch","subject":"Re: Recording the current branch on each commit?","fromName":"James Denholm","fromEmail":"nod.helm@gmail.com","sentAt":"2014-04-29T21:04:49Z","receivedAt":"2014-04-29T21:04:49Z","isPatch":false,"sender":{"key":"nod.helm@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1721189?v=4"},"body":"On 29 April 2014 23:31:29 GMT+10:00, Felipe Contreras wrote:\n>James Denholm wrote:\n>> So that we can all have egg on our faces when it takes off and is\n>> proven superior... Right?\n>\n>I don't know what you mean by \"we\", but it certainly doesn't include\n>you.\n>\n> % git log --author=nod.helm@gmail.com master\n> empty\n\nSure it does. I didn't (and don't) have any impact on the\ndebate and resulting community views, but I recall recently\nthat I prescribed to the arguments that default aliases\nare a bad idea. I'm not arrogant enough to suggest that\nmy views matter at this point, but if git-fc is proven superior\nby community adoption, I would be as wrong as anyone else\nwho held that view.\n\nSo I'll ask again - you've described frustration at the\npace of git development, and that you feel that your patches\naren't being accepted. If you feel that this is ultimately to the\nfatal detriment of git, why are you still trying to convince\nvegetarians to join you in hunting when you could simply find\na more willing group?\n\nRegards,\nJames Denholm.\n"},{"id":"240209","messageId":"53601d818409d_2f8c107d31055@nysa.notmuch","threadId":"36508","inReplyTo":"e31d0160-c7e1-4e80-93bb-d1da590eb8b5@email.android.com","subject":"Re: Recording the current branch on each commit?","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-29T21:45:37Z","receivedAt":"2014-04-29T21:45:37Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"James Denholm wrote:\n> On 29 April 2014 23:31:29 GMT+10:00, Felipe Contreras wrote:\n> >James Denholm wrote:\n> >> So that we can all have egg on our faces when it takes off and is\n> >> proven superior... Right?\n> >\n> >I don't know what you mean by \"we\", but it certainly doesn't include\n> >you.\n> >\n> > % git log --author=nod.helm@gmail.com master\n> > empty\n> \n> Sure it does.\n\nNo it doesn't. Unless you have some credentials in the Git community,\nwhich come after several contributions, your opinion carries no weight\nat all. This might not be ideal, but that's the way it is.\n\nYou have no credentials, your opinion doesn't count. You are not part of\nthe \"we\" you referred before.\n\n> So I'll ask again - you've described frustration at the\n> pace of git development, and that you feel that your patches\n> aren't being accepted. If you feel that this is ultimately to the\n> fatal detriment of git, why are you still trying to convince\n> vegetarians to join you in hunting when you could simply find\n> a more willing group?\n\nIf by convince you mean apply my patches, my patches are still getting\napplied [1].\n\nEither way your analogy is completely wrong as I already explained\nmultiple times. I'm not trying to convince vegetarians to go hunting,\nI'm saying they should eat something, bread, meat, vegetables, anything.\nInstead they choose to starve to death.\n\nAnd I'm done discussing with you. Your comments are content-free.\n\n[1] https://www.ohloh.net/p/git/contributors?sort=latest_commit\n\n-- \nFelipe Contreras\n"},{"id":"240207","messageId":"CAA01CsoSR_NzWEbD0J88ref5FM3uHt74OuVh-WesGO09XZF2uA@mail.gmail.com","threadId":"36508","inReplyTo":"535f7c35cb5b1_7c7c10e32f019@nysa.notmuch","subject":"Re: Recording the current branch on each commit?","fromName":"Piotr Krukowiecki","fromEmail":"piotr.krukowiecki@gmail.com","sentAt":"2014-04-29T21:48:45Z","receivedAt":"2014-04-29T21:48:45Z","isPatch":false,"sender":{"key":"piotr.krukowiecki@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3259959?v=4"},"body":"On Tue, Apr 29, 2014 at 12:17 PM, Felipe Contreras\n wrote:\n> That's all you could list for *four* years? None of that would even be noticed\n> by most of our users, maybe push.default (when it actually happens), but that's\n> *one*.\n>\n> *One* important change in *four* years.\n\nHi,\n\none out of how many? (How many proposed important changes were rejected?)\n\nThanks,\n-- \nPiotr Krukowiecki\n"},{"id":"240210","messageId":"alpine.DEB.2.02.1404291456080.14881@nftneq.ynat.uz","threadId":"36508","inReplyTo":"87fvkx6c4z.fsf@fencepost.gnu.org","subject":"Re: Recording the current branch on each commit?","fromName":"David Lang","fromEmail":"david@lang.hm","sentAt":"2014-04-29T21:58:08Z","receivedAt":"2014-04-29T21:58:08Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Mon, 28 Apr 2014, David Kastrup wrote:\n\n> Jeremy Morton writes:\n>\n>> On 28/04/2014 10:02, David Kastrup wrote:\n>>> Jeremy Morton writes:\n>>>\n>>>> On 28/04/2014 09:32, Felipe Contreras wrote:\n>>>>>>> some people to is to always merge with --no-ff, that way you see the branch\n>>>>>>> name in the merge commit.\n>>>>>>\n>>>>>> But surely, it's recommended with Git that you try to avoid doing\n>>>>>> --no-ff merges to avoid commit noise?\n>>>>>\n>>>>> Nope. Different people have different needs, there's no recommendation. If\n>>>>> anything, the recommendation is to do a ff merge, because that's the default.\n>>>>\n>>>> That's what I'm saying. With an ff merge, you don't get the merge\n>>>> commit message telling you the branch name.\n>>>\n>>> And I don't _want_ that branch name to be recorded. The whole point of\n>>> a distributed version control system is that it's nobody else's business\n>>> how I organize my work before submitting it.\n>>\n>> Well it would be optional, so obviously you wouldn't be forced to\n>> share the branch name. It's not like we're trying to \"pry in\" to your\n>> private development. It's a way of choosing to share what you may\n>> consider to be useful contextual information about the commit.\n\nIt sounds like what you want is really a template for a commit message that lets \nyou include arbitrary information in that template, including things like branch \nname that may not make sense for other people.\n\nIf there is no commit message, populate the template and show that to the user \nin their editor.\n\nIf there is a commit message, don't touch it.\n\nThen people can use whatever they want (including environment variables) as part \nof their messages.\n\nDavid Lang\n"},{"id":"240218","messageId":"alpine.DEB.2.02.1404291512420.14881@nftneq.ynat.uz","threadId":"36508","inReplyTo":"535E1C7A.3040504@game-point.net","subject":"Re: Recording the current branch on each commit?","fromName":"David Lang","fromEmail":"david@lang.hm","sentAt":"2014-04-29T22:14:17Z","receivedAt":"2014-04-29T22:14:17Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Mon, 28 Apr 2014, Jeremy Morton wrote:\n\n> On 28/04/2014 10:09, Johan Herland wrote:\n>> On Mon, Apr 28, 2014 at 11:01 AM, Jeremy Morton \n>> wrote:\n>>> On 28/04/2014 07:45, Christian Couder wrote:\n>>>> Yes, it's possible. Yesterday, I sent the following patch:\n>>>> \n>>>> [RFC/PATCH 2/2] trailer: add examples to the documentation\n>>>> \n>>>> and it shows a commit-msg hook to do something like that:\n>>>> \n>>>> $ cat>.git/hooks/commit-msg<>>> #!/bin/sh\n>>>> git interpret-trailers --trim-empty --trailer \"git-version: \\$(git\n>>>> describe)\" \"\\$1\"> \"\\$1.new\"\n>>>> mv \"\\$1.new\" \"\\$1\"\n>>>> EOF\n>>>> $ chmod +x .git/hooks/commit-msg\n>>>> \n>>>> I think you just need to use the following if you want the branch\n>>>> instead of the git version:\n>>>> \n>>>> git interpret-trailers --trim-empty --trailer \"git-branch: \\$(git \n>>>> name-rev\n>>>> --name-only HEAD)\" \"\\$1\"> \"\\$1.new\"\n>>>> \n>>>> It could even be simpler if there was an option (which has already\n>>>> been discussed) that made it possible to modify the file in\n>>>> place. This way one would not need the 'mv \"\\$1.new\" \"\\$1\"' command.\n>>> \n>>> This is certainly going in the right direction, but it's still implemented\n>>> as a hook on a per-repo basis. Do you foresee a point in the future where\n>>> these trailers could be added through simple one-liners in someone's \n>>> global\n>>> .gitconfig file? That's where I'd really like to get to.\n>> \n>> It's a hack, but it works surprisingly well in practice (assuming that\n>> you and your co-workers all agree that this is an acceptable\n>> approach):\n>>\n>> 1. Write the hook script and add it to your project (in a git-hooks\n>> subdir or something)\n>>\n>> 2. Add a post-checkout hook to install the first hook and the\n>> post-checkout hook itself into the user's .git/hooks/ dir.\n>>\n>> 3. Tell your co-workers to run the post-checkout hook script manually\n>> the first time. After that, the script should take care of updating\n>> itself and any hooks that you add to the project.\n>> \n>> \n>> ...Johan\n>\n> I don't understand why the co-workers need to run the post-checkout hook \n> script manually the first time?\n\nbecause git does not trust the contents of the repository, so it won't \nauto-execute a hook that's part of the respository.\n\nYou can include a hook, and then have someone run it, and after that it will be \ninstalled locally and run after every pull (and can therefor replace itself), \nbut it requires that they run it manually the first time.\n\nDavid Lang\n"},{"id":"240249","messageId":"e904f1b8-56eb-4584-9f2e-5a842c870aa0@email.android.com","threadId":"36508","inReplyTo":"53601d818409d_2f8c107d31055@nysa.notmuch","subject":"Re: Recording the current branch on each commit?","fromName":"James Denholm","fromEmail":"nod.helm@gmail.com","sentAt":"2014-04-29T22:25:03Z","receivedAt":"2014-04-29T22:25:03Z","isPatch":false,"sender":{"key":"nod.helm@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1721189?v=4"},"body":"On 30 April 2014 07:45:37 GMT+10:00, Felipe Contreras wrote:\n>James Denholm wrote:\n>> On 29 April 2014 23:31:29 GMT+10:00, Felipe Contreras\n> wrote:\n>> >James Denholm wrote:\n>> >> So that we can all have egg on our faces when it takes off and is\n>> >> proven superior... Right?\n>> >\n>> >I don't know what you mean by \"we\", but it certainly doesn't include\n>> >you.\n>> >\n>> > % git log --author=nod.helm@gmail.com master\n>> > empty\n>> \n>> Sure it does.\n>\n>No it doesn't. Unless you have some credentials in the Git community,\n>which come after several contributions, your opinion carries no weight\n>at all. This might not be ideal, but that's the way it is.\n>\n>You have no credentials, your opinion doesn't count. You are not part\n>of\n>the \"we\" you referred before.\n\nI find your lack of reading comprehension... disturbing.\n\nTo reassert the my full statement, as you so hastily truncated:\n\n>James Denholm wrote:\n> Sure it does. I didn't (and don't) have any impact on the\n> debate and resulting community views, but I recall recently\n> that I prescribed to the arguments that default aliases\n> are a bad idea. I'm not arrogant enough to suggest that\n> my views matter at this point, but if git-fc is proven superior\n> by community adoption, I would be as wrong as anyone else\n> who held that view.\n\n>> So I'll ask again - you've described frustration at the\n>> pace of git development, and that you feel that your patches\n>> aren't being accepted. If you feel that this is ultimately to the\n>> fatal detriment of git, why are you still trying to convince\n>> vegetarians to join you in hunting when you could simply find\n>> a more willing group?\n>\n>If by convince you mean apply my patches, my patches are still getting\n>applied [1].\n>\n> (...)\n>\n>[1] https://www.ohloh.net/p/git/contributors?sort=latest_commit\n\nBut that isn't the case. If it was, you wouldn't have a blog post\nup about how git-fc has default aliases (and such), while git\ndoes not. You wouldn't have another post exclaiming\nfrustration at the pace of development, and how certain\ncontributions of yours have been ignored.\n\nSure, a subset of your patches are being accepted, but if\nthe ones you cared about weren't, this discussion\nwouldn't have even occurred.\n\n>Either way your analogy is completely wrong as I already explained\n>multiple times. I'm not trying to convince vegetarians to go hunting,\n>I'm saying they should eat something, bread, meat, vegetables,\n>anything.\n>Instead they choose to starve to death.\n\nNot at all. You propose solutions, rather than *just* calling\nfor any solution to be accepted. I'm the meantime, the\ncommunity decides that some of your proposals\naren't good ideas, and decide to consider others in due\ncourse.\n\n>And I'm done discussing with you. Your comments are content-free.\n\nOnly code-free. And that's because this is a people problem,\nFelipe, not a code problem.\n\nRegards,\nJames Denholm.\n"},{"id":"240257","messageId":"53603042d6e18_c48df1308b9@nysa.notmuch","threadId":"36508","inReplyTo":"e904f1b8-56eb-4584-9f2e-5a842c870aa0@email.android.com","subject":"Re: Recording the current branch on each commit?","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-29T23:05:38Z","receivedAt":"2014-04-29T23:05:38Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"James Denholm wrote:\n> > Either way your analogy is completely wrong as I already explained\n> > multiple times. I'm not trying to convince vegetarians to go\n> > hunting, I'm saying they should eat something, bread, meat,\n> > vegetables, anything. Instead they choose to starve to death.\n> \n> I'm the meantime, the community decides that some of your proposals\n> aren't good ideas, and decide to consider others in due course.\n\nWrong. The problems are ackowledged, no other proposals are put forward,\nnothing gets done.\n\n-- \nFelipe Contreras\n"},{"id":"240260","messageId":"CAHYYfeGhkef9MgA56r2gMcnFjbC_bsJrvR2pPgjiuWLSU1MnCA@mail.gmail.com","threadId":"36508","inReplyTo":"53603042d6e18_c48df1308b9@nysa.notmuch","subject":"Re: Recording the current branch on each commit?","fromName":"James Denholm","fromEmail":"nod.helm@gmail.com","sentAt":"2014-04-30T00:22:30Z","receivedAt":"2014-04-30T00:22:30Z","isPatch":false,"sender":{"key":"nod.helm@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1721189?v=4"},"body":"Felipe Contreras wrote:\n> James Denholm wrote:\n>> > Either way your analogy is completely wrong as I already explained\n>> > multiple times. I'm not trying to convince vegetarians to go\n>> > hunting, I'm saying they should eat something, bread, meat,\n>> > vegetables, anything. Instead they choose to starve to death.\n>>\n>> I'm the meantime, the community decides that some of your proposals\n>> aren't good ideas, and decide to consider others in due course.\n>\n> Wrong. The problems are ackowledged, no other proposals are put forward,\n> nothing gets done.\n\nSo I'll ask again - you've described frustration at the\npace of git development, and that you feel that your patches\naren't being accepted. If you feel that this is ultimately to the\nfatal detriment of git, why are you still trying to convince\nvegetarians to join you in hunting when you could simply find\na more willing group?\n"},{"id":"240261","messageId":"5360476696df3_386912692f0d4@nysa.notmuch","threadId":"36508","inReplyTo":"CAHYYfeGhkef9MgA56r2gMcnFjbC_bsJrvR2pPgjiuWLSU1MnCA@mail.gmail.com","subject":"Re: Recording the current branch on each commit?","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-30T00:44:22Z","receivedAt":"2014-04-30T00:44:22Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"James Denholm wrote:\n> Felipe Contreras wrote:\n> > James Denholm wrote:\n> >> > Either way your analogy is completely wrong as I already explained\n> >> > multiple times. I'm not trying to convince vegetarians to go\n> >> > hunting, I'm saying they should eat something, bread, meat,\n> >> > vegetables, anything. Instead they choose to starve to death.\n> >>\n> >> I'm the meantime, the community decides that some of your proposals\n> >> aren't good ideas, and decide to consider others in due course.\n> >\n> > Wrong. The problems are ackowledged, no other proposals are put forward,\n> > nothing gets done.\n> \n> So I'll ask again - you've described frustration at the\n> pace of git development, and that you feel that your patches\n> aren't being accepted. If you feel that this is ultimately to the\n> fatal detriment of git, why are you still trying to convince\n> vegetarians to join you in hunting when you could simply find\n> a more willing group?\n\nYou are obviously not very good with analogies, or reading for that\nmatter. The answer is quoted right in the begginning of the mail.\nCongratulations, you've achieved a mail quote loop.\n\n-- \nFelipe Contreras\n"},{"id":"240262","messageId":"CAHYYfeHPum7hu_wHmrdCdr_baXR3V0XpmtZK-KzxaNB1_1D-kg@mail.gmail.com","threadId":"36508","inReplyTo":"5360476696df3_386912692f0d4@nysa.notmuch","subject":"Re: Recording the current branch on each commit?","fromName":"James Denholm","fromEmail":"nod.helm@gmail.com","sentAt":"2014-04-30T01:11:05Z","receivedAt":"2014-04-30T01:11:05Z","isPatch":false,"sender":{"key":"nod.helm@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1721189?v=4"},"body":"Felipe Contreras wrote:\n> You are obviously not very good with analogies, or reading for that\n> matter. The answer is quoted right in the begginning of the mail.\n> Congratulations, you've achieved a mail quote loop.\n\nI'll rephrase the question and it's context. Please attempt to answer\nit.\n\nYou've expressed frustration at the pace of git's development.\n\nYou've expressed frustration at how your proposals, at least a subset\nthereof, are not being chosen as solutions.\n\nYou've expressed belief that this is to the fatal detriment of git.\n\nAnd you've expressed that you believe this situation won't change.\n\nGiven that you feel you have the necessary solutions and you have\ngit-fc with which to drive them into the world, why are you sticking\naround expressing exasperation and inevitable fatality? Why not\npromote git-fc as the superior option, as upon it's succession of git\nyou would have the argument needed to back your proposals?\n\nRegards,\nJames Denholm.\n"}]}