Re: Recording the current branch on each commit?
On 29 April 2014 13:32:29 GMT+10:00, Felipe Contreras felipe.contre...@gmail.com wrote: James Denholm wrote: No, true, but my point was more related to that it's ones own task, perhaps being the better term than job, to debate the merits of one's own work when the merits are currently unknown to the rest of a community. It's still the same thing. Nobody gets assigned any tasks; people choose their own tasks, and they might choose tasks that other people were doing. Right. Instead of bashing about in the haberdashery of misinterpretation, allow me to explicitly restate my original point. You cannot expect that anybody but yourself is willing to propose, debate the merits of and otherwise defend patches that you have authored (herein your patches, implying authorship, not ownership). Some people *may*, but if they do not or do not successfully, that does not imply the stagnation of the project. Ultimately, the only person who can ensure that a patch is championed, and the only person who need feel a responsibility to, is the author, and that responsibility is only ever to themselves. TL,DR: Champion your own patches, don't ask others to. It's not Jeff's patches, they are our patches, they are part of the project. And it's not unusual for multiple people working on a patch series; oneperson doing most of the work, another adding tests, another cleaning updocumentation. It's also no unheard of from a person picking up a patch series somebody else stopped working on. This, of course, would be the _other_ case where a proposal's merits are already known and accepted by the community. No. John might have sent a patch series X, and maybe he didn't explain correctly how it would benefit the project. Later on Mark finds out how those patches would be useful for himself and takes upon himself to get them merged, so he cleans them up and send an updated version with a clear explanation of how they would be useful. It's still the same proposal X, but a different person and a different strategy to get them merged. In other words, the fact that the community has not yet accepted the merits of an approach doesn't mean that another person cannot champion it. As addressed above. The default may be wrong, you and I might agree that the default is wrong, Junio and Torvalds and RMS and The Queen of England might all agree that the default is wrong... But if we all live across from a bread shop, it's going to be a difficult task for you to convince us to go hunting. It doesn't matter if you want to go hunting and I want to buy bread, either one of those is better than starving to death. In the Git project though, we choose to starve to death. Neither were my patches picked, nor did anybody else step up with a different proposal, we just did nothing, which is what we always do. Not at all. Hunting may necessitate a negative side effect, such as betraying vegetarianism, having to go out into the jungle for five days, risk life and limb, and (worse yet) sleep in a tent. This is an especially poor decision if we honestly would prefer a loaf of bread, and we just need to find a way across the street. And again, I'm referring to the general case here, but of your views of what the solution should be clash with what the community view is, you're not going to be able to convince the community to go hunting. To tie in with the above, you sure aren't going to be able to if you don't engage in logical, calm, reasonable discourse. Regards, James. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recording the current branch on each commit?
- Ursprungligt meddelande - Från: Felipe Contreras felipe.contre...@gmail.com Till: James Denholm nod.h...@gmail.com, Felipe Contreras felipe.contre...@gmail.com Kopia: David Kastrup d...@gnu.org, Jeremy Morton ad...@game-point.net, Johan Herland jo...@herland.net, Git mailing list git@vger.kernel.org Skickat: tisdag, 29 apr 2014 5:32:29 Ämne: Re: Recording the current branch on each commit? James Denholm wrote: Felipe Contreras felipe.contre...@gmail.com wrote: James Denholm wrote: It's not anybody else's job to take your patches and drizzle them in the honey of respectable discourse. It's nobody's job to do anything. This a collaborative effort and in a collaborative effort everbody chimes in to do different things. [...] In the Git project though, we choose to starve to death. Neither were my patches picked, nor did anybody else step up with a different proposal, we just did nothing, which is what we always do. Just because you are starving, the others may not be. I'll skip dinner today. Not all people view the world the same way you do. Sometimes they don't see it because they don't share your experience. A year later other people may have come to the same conclusion as you (or not) and whatever the idea you had may come from someone else, when the world is ready. Whining won't help, it will just reduce your credibility, perhaps to the point that people won't even read a improved proposal if you come up with one. Remember this is a high volume list, so you don't get much time to explain an idea. It's a matter of karma. -- robin -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recording the current branch on each commit?
James Denholm wrote: You cannot expect that anybody but yourself is willing to propose, debate the merits of and otherwise defend patches that you have authored (herein your patches, implying authorship, not ownership). This is the original comment: David Kastrup wrote: It becomes easier to actually change things when communicating in a less abrasive and destructive manner. Which is demonstrably false, as I already explained nobody else could get these patches in, regarldless of the abrasiveness, or lack thereof. My point was that my abrasiveness is not an excuse not to do the changes, as somebody else could get them in (or a similar proposal). But they couldn't, because it's a change. Your point about me not expecting somebody else to defend my patches is irrelevant; it doesn't have anything to do with the topic, and it's not relevant in general either. I didn't ask or expect anybody to defend my patches, my point was that David Kastrup was wrong; it wouldn't be easier to change things; because change is simply not welcome. Ultimately, the only person who can ensure that a patch is championed, and the only person who need feel a responsibility to, is the author, and that responsibility is only ever to themselves. Contributors don't have any responsibility to champion their patches. It is pro bono work. I should champion my patches because I want to improve Git, not because I have a responsibility. And nobody else has any responsibility either, but if somebody else want to improve Git as well, they should chamption the patches (or others of their own) as well. In the meantime the problem still remains. It doesn't matter if you want to go hunting and I want to buy bread, either one of those is better than starving to death. Not at all. Hunting may necessitate a negative side effect, such as betraying vegetarianism, having to go out into the jungle for five days, risk life and limb, and (worse yet) sleep in a tent. This is an especially poor decision if we honestly would prefer a loaf of bread, and we just need to find a way across the street. You obviously didn't read what I said. And again, I'm referring to the general case here, but of your views of what the solution should be clash with what the community view is, you're not going to be able to convince the community to go hunting. I'm not going to convince them to buy bread either. The community wants to starve to death, and you couldn't convince them otherwise either. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recording the current branch on each commit?
Felipe Contreras felipe.contre...@gmail.com writes: Contributors don't have any responsibility to champion their patches. It is pro bono work. No, that's just the appearance that should be upheld in the higher society. It's ok to get paid for work on Git as long as you don't mention it in public. It's also ok to get paid for _promises_ of work if you can make people believe you. Open Source is not much different from how politics and society in general work in the U.S.A. To get the real wads of money, you first need to get the means not to have to talk about money (it's ok if you do it by means totally opposed to the political cause as long as you don't talk about it), then you have to prefinance people's trust in you not being there for the money, and then you are in a position to get paid for your work. Anyway, I digress. Even without all that not so pro bono background to pro bono work, there is still a difference between pro bono work ending up in the wastebin and pro bono work ending up in a product. Even while the ones getting the benefits from your work will not feel an obligation to make it worth your while, there is a difference in satisfaction between getting your work trashed and getting it used. The satisfaction by exploding in self-righteousness tends to be a poor substitute and is comparatively short-lived. Yes, it may mean that you have to carry your child the last yards rather than shout it across the finishing line. Even though it should have legs perfectly suited to get it across the track on its own. Only that way you get to pat it on its head. -- David Kastrup -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recording the current branch on each commit?
David Kastrup wrote: Felipe Contreras felipe.contre...@gmail.com writes: Contributors don't have any responsibility to champion their patches. It is pro bono work. No, that's just the appearance that should be upheld in the higher society. It's ok to get paid for work on Git as long as you don't mention it in public. The word contribute implies doing something that was not necessary. If somebody is paying you to do something, then it's not a contribution, it is simply your duty. That's why I used the word contributors, to separate the people that don't have a responsability, and the ones that do. Even while the ones getting the benefits from your work will not feel an obligation to make it worth your while, there is a difference in satisfaction between getting your work trashed and getting it used. I don't know why this keeps poping up in the thread, but it is starting to seem to me that you are under the impression that I'm somehow unable to get my patches merged. Look at the list of contributors of the past year, see who is #2: https://www.ohloh.net/p/git/contributors?query=sort=commits_12_mo I know what kind of patches can get in, and what patches can't (the ones that do any kind of relevant change). I know that from experience. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recording the current branch on each commit?
David Kastrup wrote: Felipe Contreras felipe.contre...@gmail.com writes: David Kastrup wrote: Even while the ones getting the benefits from your work will not feel an obligation to make it worth your while, there is a difference in satisfaction between getting your work trashed and getting it used. I don't know why this keeps poping up in the thread, but it is starting to seem to me that you are under the impression that I'm somehow unable to get my patches merged. Look at the list of contributors of the past year, see who is #2: https://www.ohloh.net/p/git/contributors?query=sort=commits_12_mo I know what kind of patches can get in, and what patches can't (the ones that do any kind of relevant change). I know that from experience. Well, there you have it. The ones that do any kind of relevant change are the ones that need thinking about and consideration. And when you are so verbose about them that a) you are getting on people's nerves b) nobody else finds something worth saying that you did not already say then the net effect is that it feels to the person in question he's mainly doing you (and not all that many others) a favor by investing the work for properly considering it and its consequences. This is the last time I say it: this is demonstrably false. You claim that relevant changes can be made if the submitter is not so verbose (and less aggressive and what not). This is obviously not the case. Show me any change of importance done in the last two years, hell, make it four. And by change I mean something that was one way before, and was another way after. There is nothing. It doesn't matter how these changes are presented. Changes are not welcome, doesn't matter who is championing them, or how. Period. At any rate, we are in a phase supposed to be shortly before the release of 2.0. This is a red herring. All the patches I'm talking about were sent well before 2.0 was imminent, six months to one year ago. Even more, I'm challenging you to find an important change since even four years ago. You won't find any. But it might do so regarding 2.1. No, it won't. Neither 3.0. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recording the current branch on each commit?
Felipe Contreras felipe.contre...@gmail.com writes: David Kastrup wrote: Well, there you have it. The ones that do any kind of relevant change are the ones that need thinking about and consideration. And when you are so verbose about them that a) you are getting on people's nerves b) nobody else finds something worth saying that you did not already say then the net effect is that it feels to the person in question he's mainly doing you (and not all that many others) a favor by investing the work for properly considering it and its consequences. This is the last time I say it: this is demonstrably false. Feelings are not categorizable as demonstrably false. You claim that relevant changes can be made if the submitter is not so verbose (and less aggressive and what not). This is obviously not the case. Show me any change of importance done in the last two years, hell, make it four. And by change I mean something that was one way before, and was another way after. The default behavior of git push. Colorized diffs. git add dir/ can now remove files. git gc --aggressive has been sanitized. -- David Kastrup -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recording the current branch on each commit?
David Kastrup wrote: Felipe Contreras felipe.contre...@gmail.com writes: David Kastrup wrote: Well, there you have it. The ones that do any kind of relevant change are the ones that need thinking about and consideration. And when you are so verbose about them that a) you are getting on people's nerves b) nobody else finds something worth saying that you did not already say then the net effect is that it feels to the person in question he's mainly doing you (and not all that many others) a favor by investing the work for properly considering it and its consequences. This is the last time I say it: this is demonstrably false. Feelings are not categorizable as demonstrably false. It's demonsrable by the challenge below. You claim that relevant changes can be made if the submitter is not so verbose (and less aggressive and what not). This is obviously not the case. Show me any change of importance done in the last two years, hell, make it four. And by change I mean something that was one way before, and was another way after. The default behavior of git push. This is a minor change that not many people would notice, and it has not actually happend. But fine, let's count it as one. Colorized diffs. That's not a change. git add dir/ That doesn't count as an important change. can now remove files. Irrelevant. git gc --aggressive has been sanitized. Irrelevant. Nobody did notice. That's all you could list for *four* years? None of that would even be noticed by most of our users, maybe push.default (when it actually happens), but that's *one*. *One* important change in *four* years. That's demonstration that change just does not happen. And if you disagree, then we'll agree to disagree. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recording the current branch on each commit?
Felipe Contreras felipe.contre...@gmail.com writes: David Kastrup wrote: The default behavior of git push. This is a minor change that not many people would notice, and it has not actually happend. But fine, let's count it as one. Shrug. Your diatribe is to a good part about the default behavior of git pull. The minor change affects multiple branches in upstream, while your important change affects a single local branch. With that sort of bias, it's easy to convince yourself of anything. -- David Kastrup -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recording the current branch on each commit?
I've no right to say this, given that I've no contributions thus far to the project, little history in open source at all, and have only been following the list for less than a week, but I'll say it anyway, mayhaps. And I don't mean this to cause offence, or inspire outrage, or any similar sort of thing. I mean this only with good intentions. But Felipe, if you honestly feel that git has stagnated, and that your contributions aren't wanted because we'd rather starve, then perhaps git isn't the right project for you. I'm not saying that you shouldn't work on the git codebase, you could very easily fork it and make the innovative SCMS none of us can see, and kill git. Can be done, if hunting really is the best choice as you say. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recording the current branch on each commit?
David Kastrup wrote: Felipe Contreras felipe.contre...@gmail.com writes: David Kastrup wrote: The default behavior of git push. This is a minor change that not many people would notice, and it has not actually happend. But fine, let's count it as one. Shrug. Your diatribe is to a good part about the default behavior of git pull. The minor change affects multiple branches in upstream, This is what most people see by default since two years ago: warning: push.default is unset; its implicit value is changing in Git 2.0 from 'matching' to 'simple'. To squelch this message and maintain the current behavior after the default changes, use: git config --global push.default matching To squelch this message and adopt the new behavior now, use: git config --global push.default simple When push.default is set to 'matching', git will push local branches to the remote branches that already exist with the same name. In Git 2.0, Git will default to the more conservative 'simple' behavior, which only pushes the current branch to the corresponding remote branch that 'git pull' uses to update the current branch. See 'git help config' and search for 'push.default' for further information. (the 'simple' mode was introduced in Git 1.7.11. Use the similar mode 'current' instead of 'simple' if you sometimes use older versions of Git) Do you honestly believe that there's *anybody* out there is OK with seeing this message _every_ _single_ _time_ he pushes? No. Everybody has already configured push.default to one thing or the other. They won't see the change when 2.0 is released. And no, if by some miracle somebody hasn't configured that, it still won't affect the branches upstream, if anything changes is that the `git pull` will error out warning the user that the upstream branch doesn't have the same name. It won't affect the branches you actually push. while your important change affects a single local branch. My change does actually affect upstream branches, more than that, it affects the upstream topology, because Git newcomers make merges by mistake when they call `git pull` without knowing what the hell is going on. Everybody knows that. And this is a red herring. I never said my change was important, we are talking about the changes that have actually happened in the last four years, which is none. With that sort of bias, it's easy to convince yourself of anything. I'm done discussing with you. I already demonstrated that your claim is wrong. Change just doesn't happen. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recording the current branch on each commit?
James Denholm wrote: I've no right to say this, given that I've no contributions I'm not saying that you shouldn't work on the git codebase, you could very easily fork it and make the innovative SCMS none of us can see, and kill git. Can be done, if hunting really is the best choice as you say. I already made a fork: http://felipec.wordpress.com/2013/10/28/git-fc/ -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recording the current branch on each commit?
On 29 April 2014 21:47:42 GMT+10:00, Felipe Contreras felipe.contre...@gmail.com wrote: James Denholm wrote: I've no right to say this, given that I've no contributions I'm not saying that you shouldn't work on the git codebase, you could very easily fork it and make the innovative SCMS none of us can see, and kill git. Can be done, if hunting really is the best choice as you say. I already made a fork: http://felipec.wordpress.com/2013/10/28/git-fc/ Sweet. So now you're going to get open source journalism interested in git-fc and gain a groundswell of support, right? So that we can all have egg on our faces when it takes off and is proven superior... Right? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recording the current branch on each commit?
James Denholm wrote: So that we can all have egg on our faces when it takes off and is proven superior... Right? I don't know what you mean by we, but it certainly doesn't include you. % git log --author=nod.h...@gmail.com master empty -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recording the current branch on each commit?
On 29 April 2014 23:31:29 GMT+10:00, Felipe Contreras felipe.contre...@gmail.com wrote: James Denholm wrote: So that we can all have egg on our faces when it takes off and is proven superior... Right? I don't know what you mean by we, but it certainly doesn't include you. % git log --author=nod.h...@gmail.com master empty Sure it does. I didn't (and don't) have any impact on the debate and resulting community views, but I recall recently that I prescribed to the arguments that default aliases are a bad idea. I'm not arrogant enough to suggest that my views matter at this point, but if git-fc is proven superior by community adoption, I would be as wrong as anyone else who held that view. So I'll ask again - you've described frustration at the pace of git development, and that you feel that your patches aren't being accepted. If you feel that this is ultimately to the fatal detriment of git, why are you still trying to convince vegetarians to join you in hunting when you could simply find a more willing group? Regards, James Denholm. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recording the current branch on each commit?
On Tue, Apr 29, 2014 at 12:17 PM, Felipe Contreras felipe.contre...@gmail.com wrote: That's all you could list for *four* years? None of that would even be noticed by most of our users, maybe push.default (when it actually happens), but that's *one*. *One* important change in *four* years. Hi, one out of how many? (How many proposed important changes were rejected?) Thanks, -- Piotr Krukowiecki -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recording the current branch on each commit?
James Denholm wrote: On 29 April 2014 23:31:29 GMT+10:00, Felipe Contreras felipe.contre...@gmail.com wrote: James Denholm wrote: So that we can all have egg on our faces when it takes off and is proven superior... Right? I don't know what you mean by we, but it certainly doesn't include you. % git log --author=nod.h...@gmail.com master empty Sure it does. No it doesn't. Unless you have some credentials in the Git community, which come after several contributions, your opinion carries no weight at all. This might not be ideal, but that's the way it is. You have no credentials, your opinion doesn't count. You are not part of the we you referred before. So I'll ask again - you've described frustration at the pace of git development, and that you feel that your patches aren't being accepted. If you feel that this is ultimately to the fatal detriment of git, why are you still trying to convince vegetarians to join you in hunting when you could simply find a more willing group? If by convince you mean apply my patches, my patches are still getting applied [1]. Either way your analogy is completely wrong as I already explained multiple times. I'm not trying to convince vegetarians to go hunting, I'm saying they should eat something, bread, meat, vegetables, anything. Instead they choose to starve to death. And I'm done discussing with you. Your comments are content-free. [1] https://www.ohloh.net/p/git/contributors?sort=latest_commit -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recording the current branch on each commit?
On Mon, 28 Apr 2014, David Kastrup wrote: Jeremy Morton ad...@game-point.net writes: On 28/04/2014 10:02, David Kastrup wrote: Jeremy Mortonad...@game-point.net writes: On 28/04/2014 09:32, Felipe Contreras wrote: some people to is to always merge with --no-ff, that way you see the branch name in the merge commit. But surely, it's recommended with Git that you try to avoid doing --no-ff merges to avoid commit noise? Nope. Different people have different needs, there's no recommendation. If anything, the recommendation is to do a ff merge, because that's the default. That's what I'm saying. With an ff merge, you don't get the merge commit message telling you the branch name. And I don't _want_ that branch name to be recorded. The whole point of a distributed version control system is that it's nobody else's business how I organize my work before submitting it. Well it would be optional, so obviously you wouldn't be forced to share the branch name. It's not like we're trying to pry in to your private development. It's a way of choosing to share what you may consider to be useful contextual information about the commit. It sounds like what you want is really a template for a commit message that lets you include arbitrary information in that template, including things like branch name that may not make sense for other people. If there is no commit message, populate the template and show that to the user in their editor. If there is a commit message, don't touch it. Then people can use whatever they want (including environment variables) as part of their messages. David Lang -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recording the current branch on each commit?
On Mon, 28 Apr 2014, Jeremy Morton wrote: On 28/04/2014 10:09, Johan Herland wrote: On Mon, Apr 28, 2014 at 11:01 AM, Jeremy Mortonad...@game-point.net wrote: On 28/04/2014 07:45, Christian Couder wrote: Yes, it's possible. Yesterday, I sent the following patch: [RFC/PATCH 2/2] trailer: add examples to the documentation and it shows a commit-msg hook to do something like that: $ cat.git/hooks/commit-msgEOF #!/bin/sh git interpret-trailers --trim-empty --trailer git-version: \$(git describe) \$1 \$1.new mv \$1.new \$1 EOF $ chmod +x .git/hooks/commit-msg I think you just need to use the following if you want the branch instead of the git version: git interpret-trailers --trim-empty --trailer git-branch: \$(git name-rev --name-only HEAD) \$1 \$1.new It could even be simpler if there was an option (which has already been discussed) that made it possible to modify the file in place. This way one would not need the 'mv \$1.new \$1' command. This is certainly going in the right direction, but it's still implemented as a hook on a per-repo basis. Do you foresee a point in the future where these trailers could be added through simple one-liners in someone's global .gitconfig file? That's where I'd really like to get to. It's a hack, but it works surprisingly well in practice (assuming that you and your co-workers all agree that this is an acceptable approach): 1. Write the hook script and add it to your project (in a git-hooks subdir or something) 2. Add a post-checkout hook to install the first hook and the post-checkout hook itself into the user's .git/hooks/ dir. 3. Tell your co-workers to run the post-checkout hook script manually the first time. After that, the script should take care of updating itself and any hooks that you add to the project. ...Johan I don't understand why the co-workers need to run the post-checkout hook script manually the first time? because git does not trust the contents of the repository, so it won't auto-execute a hook that's part of the respository. You can include a hook, and then have someone run it, and after that it will be installed locally and run after every pull (and can therefor replace itself), but it requires that they run it manually the first time. David Lang -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recording the current branch on each commit?
On 30 April 2014 07:45:37 GMT+10:00, Felipe Contreras felipe.contre...@gmail.com wrote: James Denholm wrote: On 29 April 2014 23:31:29 GMT+10:00, Felipe Contreras felipe.contre...@gmail.com wrote: James Denholm wrote: So that we can all have egg on our faces when it takes off and is proven superior... Right? I don't know what you mean by we, but it certainly doesn't include you. % git log --author=nod.h...@gmail.com master empty Sure it does. No it doesn't. Unless you have some credentials in the Git community, which come after several contributions, your opinion carries no weight at all. This might not be ideal, but that's the way it is. You have no credentials, your opinion doesn't count. You are not part of the we you referred before. I find your lack of reading comprehension... disturbing. To reassert the my full statement, as you so hastily truncated: James Denholm wrote: Sure it does. I didn't (and don't) have any impact on the debate and resulting community views, but I recall recently that I prescribed to the arguments that default aliases are a bad idea. I'm not arrogant enough to suggest that my views matter at this point, but if git-fc is proven superior by community adoption, I would be as wrong as anyone else who held that view. So I'll ask again - you've described frustration at the pace of git development, and that you feel that your patches aren't being accepted. If you feel that this is ultimately to the fatal detriment of git, why are you still trying to convince vegetarians to join you in hunting when you could simply find a more willing group? If by convince you mean apply my patches, my patches are still getting applied [1]. (...) [1] https://www.ohloh.net/p/git/contributors?sort=latest_commit But that isn't the case. If it was, you wouldn't have a blog post up about how git-fc has default aliases (and such), while git does not. You wouldn't have another post exclaiming frustration at the pace of development, and how certain contributions of yours have been ignored. Sure, a subset of your patches are being accepted, but if the ones you cared about weren't, this discussion wouldn't have even occurred. Either way your analogy is completely wrong as I already explained multiple times. I'm not trying to convince vegetarians to go hunting, I'm saying they should eat something, bread, meat, vegetables, anything. Instead they choose to starve to death. Not at all. You propose solutions, rather than *just* calling for any solution to be accepted. I'm the meantime, the community decides that some of your proposals aren't good ideas, and decide to consider others in due course. And I'm done discussing with you. Your comments are content-free. Only code-free. And that's because this is a people problem, Felipe, not a code problem. Regards, James Denholm. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recording the current branch on each commit?
James Denholm wrote: Either way your analogy is completely wrong as I already explained multiple times. I'm not trying to convince vegetarians to go hunting, I'm saying they should eat something, bread, meat, vegetables, anything. Instead they choose to starve to death. I'm the meantime, the community decides that some of your proposals aren't good ideas, and decide to consider others in due course. Wrong. The problems are ackowledged, no other proposals are put forward, nothing gets done. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recording the current branch on each commit?
Felipe Contreras wrote: James Denholm wrote: Either way your analogy is completely wrong as I already explained multiple times. I'm not trying to convince vegetarians to go hunting, I'm saying they should eat something, bread, meat, vegetables, anything. Instead they choose to starve to death. I'm the meantime, the community decides that some of your proposals aren't good ideas, and decide to consider others in due course. Wrong. The problems are ackowledged, no other proposals are put forward, nothing gets done. So I'll ask again - you've described frustration at the pace of git development, and that you feel that your patches aren't being accepted. If you feel that this is ultimately to the fatal detriment of git, why are you still trying to convince vegetarians to join you in hunting when you could simply find a more willing group? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recording the current branch on each commit?
James Denholm wrote: Felipe Contreras wrote: James Denholm wrote: Either way your analogy is completely wrong as I already explained multiple times. I'm not trying to convince vegetarians to go hunting, I'm saying they should eat something, bread, meat, vegetables, anything. Instead they choose to starve to death. I'm the meantime, the community decides that some of your proposals aren't good ideas, and decide to consider others in due course. Wrong. The problems are ackowledged, no other proposals are put forward, nothing gets done. So I'll ask again - you've described frustration at the pace of git development, and that you feel that your patches aren't being accepted. If you feel that this is ultimately to the fatal detriment of git, why are you still trying to convince vegetarians to join you in hunting when you could simply find a more willing group? You are obviously not very good with analogies, or reading for that matter. The answer is quoted right in the begginning of the mail. Congratulations, you've achieved a mail quote loop. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recording the current branch on each commit?
Felipe Contreras wrote: You are obviously not very good with analogies, or reading for that matter. The answer is quoted right in the begginning of the mail. Congratulations, you've achieved a mail quote loop. I'll rephrase the question and it's context. Please attempt to answer it. You've expressed frustration at the pace of git's development. You've expressed frustration at how your proposals, at least a subset thereof, are not being chosen as solutions. You've expressed belief that this is to the fatal detriment of git. And you've expressed that you believe this situation won't change. Given that you feel you have the necessary solutions and you have git-fc with which to drive them into the world, why are you sticking around expressing exasperation and inevitable fatality? Why not promote git-fc as the superior option, as upon it's succession of git you would have the argument needed to back your proposals? Regards, James Denholm. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recording the current branch on each commit?
On Mon, Apr 28, 2014 at 11:15:10AM -0700, Junio C Hamano wrote: Any additional information about the commit can be added you suggest is exactly the kind of thing we want to avoid, which made Linus say in an even older discussion [*2*]: No this random field could be used this random way crud, please. I see, thanks for explanation. -- Max -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recording the current branch on each commit?
Johan Herland jo...@herland.net writes: Obviously, the feature would necessarily have to be optional, simply because Git would have to keep understanding the old commit object format for a LONG time (probably indefinitely), and there's nothing you can do to prevent others from creating old-style commit objects. Personally, I am _strongly_ opposed. How I name and juggle my private branches is nobody else's business in a distributed version control system. They are private. My personal workflow. Not part of a commit. -- David Kastrup -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Recording the current branch on each commit?
Hi. Obviously, the feature would necessarily have to be optional, simply because Git would have to keep understanding the old commit object format for a LONG time (probably indefinitely), and there's nothing you can do to prevent others from creating old-style commit objects. Doesn't git ignores unknown headers? I has been investigating this issue and it looked like it does. Could the API to add commit headers (which exists in sources) be added to cli, so users can create the branches, phases or whatever they feel useful? -- Max -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Recording the current branch on each commit?
Personally, I am _strongly_ opposed. How I name and juggle my private branches is nobody else's business in a distributed version control system. They are private. My personal workflow. Not part of a commit. Mercurial inherits the branch label from previous commit, unless it's specified by user, I think this could be quite reasonable behavior. (if make them at all, I don't think this specific branch label feature should be implemented in git core, but rather there should be a way to extend git so that it makes them) -- Max -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recording the current branch on each commit?
From: Johan Herland jo...@herland.net Subject: Re: Recording the current branch on each commit? Date: Mon, 28 Apr 2014 01:39:26 +0200 On Sun, Apr 27, 2014 at 10:55 PM, Jeremy Morton ad...@game-point.net wrote: On 27/04/2014 20:33, Johan Herland wrote: On Sun, Apr 27, 2014 at 7:38 PM, Jeremy Mortonad...@game-point.net wrote: On 27/04/2014 10:09, Johan Herland wrote: As far as I can tell from that discussion, the general opposition to encoding the branch name as a structural part of the commit object is that, for some people's workflows, it would be unhelpful and/or misleading. Well fair enough then - why don't we make it a setting that is off by default, and can easily be switched on? That way the people for whom tagging the branch name would be useful have a very easy way to switch it on. Therefore, the most pragmatic and constructive thing to do at this point, is IMHO to work within the confines of the existing commit object structure. I actually believe using commit message trailers like Made-on-branch: frotz in addition to some helpful infrastructure (hooks, templates, git-interpret-trailers, etc.) should get you pretty much exactly what you want. And if this feature turns out to be extremely useful for a lot of users, we can certainly consider changing the commit object format in the future. OK, fair enough. So I guess what I'd like to see, then, is good built-in functionality in Git for these commit message trailers, so that they are very easy to turn on. I'd like to be able to tell co-developers to add a one-liner to their git config file rather than some post-commit script. I think this is what the interpret-trailers effort is about. Unfortunately I have not followed it closely enough to say if your use case is already covered by Christian's (CCed) work. Christian: With your current patch series, is it possible for Jeremy to configure interpret-trailers to automatically append a Made-on-branch: current_branch trailer whenever he creates a commit? Yes, it's possible. Yesterday, I sent the following patch: [RFC/PATCH 2/2] trailer: add examples to the documentation and it shows a commit-msg hook to do something like that: $ cat .git/hooks/commit-msg EOF #!/bin/sh git interpret-trailers --trim-empty --trailer git-version: \$(git describe) \$1 \$1.new mv \$1.new \$1 EOF $ chmod +x .git/hooks/commit-msg I think you just need to use the following if you want the branch instead of the git version: git interpret-trailers --trim-empty --trailer git-branch: \$(git name-rev --name-only HEAD) \$1 \$1.new It could even be simpler if there was an option (which has already been discussed) that made it possible to modify the file in place. This way one would not need the 'mv \$1.new \$1' command. Best, Christian. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recording the current branch on each commit?
Jeremy Morton wrote: On 27/04/2014 09:51, Robin Rosenberg wrote: Currently, git records a checksum, author, commit date/time, and commit message with every commit (as get be seen from 'git log'). I think it would be useful if, along with the Author and Date, git recorded the name of the current branch on each commit. The branch name can provide useful contextual information. For instance, let's say I'm developing a suite of games. If the commit message says Added basic options dialog, it might be useful to see that the branch name is pacman-minigame indicating that the commit pertains to the options dialog in the Pacman minigame. Basically, I'm saying that well-named branches can and do carry useful contextual information that oughtn't to be thrown away. Currently, when you delete that branch, you lose the branch name altogether. So what do you think? Would it be good to have a patch to add this feature? Branch names are usually poorly named, so often you don't lose much. One way Speak for yourself - I give my branches useful names. :-) Me too. I definitely feel that I am often losing useful contextual information by throwing away the branch name. I don't. some people to is to always merge with --no-ff, that way you see the branch name in the merge commit. But surely, it's recommended with Git that you try to avoid doing --no-ff merges to avoid commit noise? Nope. Different people have different needs, there's no recommendation. If anything, the recommendation is to do a ff merge, because that's the default. Also, it is a lot more hassle (and no doubt, CPU cycles) to track down where a branch was merged to try and figure out which branch name a commit pertained to, not to mention the fact that the commit could've been moved since. Nothing short of tagging the commit with the branch name when the commit is made will definitely record the branch name at the time of committing. But why do you need that information? -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recording the current branch on each commit?
On 28/04/2014 09:32, Felipe Contreras wrote: some people to is to always merge with --no-ff, that way you see the branch name in the merge commit. But surely, it's recommended with Git that you try to avoid doing --no-ff merges to avoid commit noise? Nope. Different people have different needs, there's no recommendation. If anything, the recommendation is to do a ff merge, because that's the default. That's what I'm saying. With an ff merge, you don't get the merge commit message telling you the branch name. Also, it is a lot more hassle (and no doubt, CPU cycles) to track down where a branch was merged to try and figure out which branch name a commit pertained to, not to mention the fact that the commit could've been moved since. Nothing short of tagging the commit with the branch name when the commit is made will definitely record the branch name at the time of committing. But why do you need that information? As I said before, I usually consider my branch names useful information worth keeping around - I'm not sure why you don't. I might include a bug# in the branch name so I don't have to keep typing it in every commit message, or I might just have a handy short description of what part of the application this branch is modifying (like my pacman-minigame example). -- Best regards, Jeremy Morton (Jez) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recording the current branch on each commit?
On 28/04/2014 03:30, Sitaram Chamarty wrote: On 04/28/2014 01:03 AM, Johan Herland wrote: Yeah, sure. Author and Date (and Committer, for that matter) is just metadata, and the current branch name is simply just another kind of metadata. All of them are more-or-less free-form text fields, and off no they're not. In strictly controlled environments they form part of the audit record for the source code. Yes they can be faked (explicitly), but -- again in strictly controlled environments -- that can be limited to before it was first pushed. Why these specific headers as part of the audit record, though? Aren't you just arbitrarily defining them as part of the audit record? -- Best regards, Jeremy Morton (Jez) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recording the current branch on each commit?
Jeremy Morton wrote: On 27/04/2014 10:09, Johan Herland wrote: On Sun, Apr 27, 2014 at 1:56 AM, Jeremy Mortonad...@game-point.net wrote: Currently, git records a checksum, author, commit date/time, and commit message with every commit (as get be seen from 'git log'). I think it would be useful if, along with the Author and Date, git recorded the name of the current branch on each commit. This has been discussed multiple times in the past. One example here: http://thread.gmane.org/gmane.comp.version-control.git/229422 I believe the current conclusion (if any) is that encoding such information as a _structural_ part of the commit object is not useful. See the old thread(s) for the actual pro/con arguments. As far as I can tell from that discussion, the general opposition to encoding the branch name as a structural part of the commit object is that, for some people's workflows, it would be unhelpful and/or misleading. s/some people's workflows/most workflows/ Well fair enough then - why don't we make it a setting that is off by default, and can easily be switched on? That way the people for whom tagging the branch name would be useful have a very easy way to switch it on. I know that for the workflows I personally have used in the past, such tagging would be very useful. Quite often I have been looking through the Git log and wondered what feature a commit was part of, because I have feature branches. Just knowing that branch name would be really useful, but the branch has since been deleted... and in the case of a ff-merge (which I thought was recommended in Git if possible), the branch name is completely gone. I still don't see why you would need that information, but if you really need it, you can write a commit hook that stores that information in the message, it's very trivial. Also, you can store that information in notes. You can go back through the history and find Merge branch 'pacman-minigame', but how do you know which commit was the *start* of that branch, if they are not tagged with the branch name? By recording the start of the branch. [1] https://github.com/felipec/git/commits/fc/tail -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recording the current branch on each commit?
On 28/04/2014 07:45, Christian Couder wrote: Yes, it's possible. Yesterday, I sent the following patch: [RFC/PATCH 2/2] trailer: add examples to the documentation and it shows a commit-msg hook to do something like that: $ cat.git/hooks/commit-msgEOF #!/bin/sh git interpret-trailers --trim-empty --trailer git-version: \$(git describe) \$1 \$1.new mv \$1.new \$1 EOF $ chmod +x .git/hooks/commit-msg I think you just need to use the following if you want the branch instead of the git version: git interpret-trailers --trim-empty --trailer git-branch: \$(git name-rev --name-only HEAD) \$1 \$1.new It could even be simpler if there was an option (which has already been discussed) that made it possible to modify the file in place. This way one would not need the 'mv \$1.new \$1' command. Best, Christian. This is certainly going in the right direction, but it's still implemented as a hook on a per-repo basis. Do you foresee a point in the future where these trailers could be added through simple one-liners in someone's global .gitconfig file? That's where I'd really like to get to. -- Best regards, Jeremy Morton (Jez) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recording the current branch on each commit?
Jeremy Morton ad...@game-point.net writes: On 28/04/2014 09:32, Felipe Contreras wrote: some people to is to always merge with --no-ff, that way you see the branch name in the merge commit. But surely, it's recommended with Git that you try to avoid doing --no-ff merges to avoid commit noise? Nope. Different people have different needs, there's no recommendation. If anything, the recommendation is to do a ff merge, because that's the default. That's what I'm saying. With an ff merge, you don't get the merge commit message telling you the branch name. And I don't _want_ that branch name to be recorded. The whole point of a distributed version control system is that it's nobody else's business how I organize my work before submitting it. I don't want to have people tell me when submitting patches but can't you give this a better branch name? and then have to use git filter-branch or whatever else to get the branch name removed. As I said before, I usually consider my branch names useful information worth keeping around - I'm not sure why you don't. It is _totally_ useless information in a distributed development model. Why would or should anybody be concerned what private branches some submitter has developed his patches in? This is not a useful part of a commit. -- David Kastrup -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recording the current branch on each commit?
Johan Herland wrote: On Sun, Apr 27, 2014 at 7:38 PM, Jeremy Morton ad...@game-point.net wrote: Whatsmore, tracking down which branch a commit pertains to is still rather difficult using this approach. You can go back through the history and find Merge branch 'pacman-minigame', but how do you know which commit was the *start* of that branch, if they are not tagged with the branch name? Once you have found the merge commit (M), git log M^1..M^2 should list all the commits that were made on that branch. The parent of the last in that list can be considered the starting point for the branch. It's not that easy. There has been a lot of discussion in the mailing list and StackOverflow of ways to do this [1]. The conclusion, at least for me, is that there's no way to find that out, so it has to be recorded. [1] http://thread.gmane.org/gmane.comp.version-control.git/198587 -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recording the current branch on each commit?
On Mon, Apr 28, 2014 at 11:01 AM, Jeremy Morton ad...@game-point.net wrote: On 28/04/2014 07:45, Christian Couder wrote: Yes, it's possible. Yesterday, I sent the following patch: [RFC/PATCH 2/2] trailer: add examples to the documentation and it shows a commit-msg hook to do something like that: $ cat.git/hooks/commit-msgEOF #!/bin/sh git interpret-trailers --trim-empty --trailer git-version: \$(git describe) \$1 \$1.new mv \$1.new \$1 EOF $ chmod +x .git/hooks/commit-msg I think you just need to use the following if you want the branch instead of the git version: git interpret-trailers --trim-empty --trailer git-branch: \$(git name-rev --name-only HEAD) \$1 \$1.new It could even be simpler if there was an option (which has already been discussed) that made it possible to modify the file in place. This way one would not need the 'mv \$1.new \$1' command. This is certainly going in the right direction, but it's still implemented as a hook on a per-repo basis. Do you foresee a point in the future where these trailers could be added through simple one-liners in someone's global .gitconfig file? That's where I'd really like to get to. It's a hack, but it works surprisingly well in practice (assuming that you and your co-workers all agree that this is an acceptable approach): 1. Write the hook script and add it to your project (in a git-hooks subdir or something) 2. Add a post-checkout hook to install the first hook and the post-checkout hook itself into the user's .git/hooks/ dir. 3. Tell your co-workers to run the post-checkout hook script manually the first time. After that, the script should take care of updating itself and any hooks that you add to the project. ...Johan -- Johan Herland, jo...@herland.net www.herland.net -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recording the current branch on each commit?
On 28/04/2014 10:02, David Kastrup wrote: Jeremy Mortonad...@game-point.net writes: On 28/04/2014 09:32, Felipe Contreras wrote: some people to is to always merge with --no-ff, that way you see the branch name in the merge commit. But surely, it's recommended with Git that you try to avoid doing --no-ff merges to avoid commit noise? Nope. Different people have different needs, there's no recommendation. If anything, the recommendation is to do a ff merge, because that's the default. That's what I'm saying. With an ff merge, you don't get the merge commit message telling you the branch name. And I don't _want_ that branch name to be recorded. The whole point of a distributed version control system is that it's nobody else's business how I organize my work before submitting it. Well it would be optional, so obviously you wouldn't be forced to share the branch name. It's not like we're trying to pry in to your private development. It's a way of choosing to share what you may consider to be useful contextual information about the commit. I don't want to have people tell me when submitting patches but can't you give this a better branch name? and then have to use git filter-branch or whatever else to get the branch name removed. As I said before, I usually consider my branch names useful information worth keeping around - I'm not sure why you don't. It is _totally_ useless information in a distributed development model. Why would or should anybody be concerned what private branches some submitter has developed his patches in? Why should anybody be concerned about what commit message some submitter has typed in for his commit? They could just read the source code to see what has changed, right? Because the commit message is a way for the submitter to try and make it easier for the people looking at the commit to understand what the commit is doing. In the same way, a meaningful branch name may also make it easier for people looking at the commit to understand what it is doing, or what part of the application it is affecting, or what group of commits it is a part of. -- Best regards, Jeremy Morton (Jez) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recording the current branch on each commit?
Jeremy Morton wrote: On 27/04/2014 20:33, Johan Herland wrote: The problem is not really less tidy commit trees - by which I gather you mean history graphs that are non-linear. IMHO, the history graph should reflect parallel/branched development when that is useful. Blindly rebasing everything into a single line is IMHO just as bad as doing all your work directly on master and blindly running git pull between each of your own commits (which results in a lot of useless merges). The merge commits themselves are not the problem. Merge commits are a tool, and when used properly (to introduce topics to the master branch like described above) they are a good tool. When abused (like blindly running git pull and accepting useless merge bubbles) they create more problems than they solve. Sounds like the default behaviour of git pull might not be ideal if it easily causes these problems. It's not idea. Virtually everyone agrees with that, even Linus Torvalds, and we have the patches to fix it, but it's not going to change. The Git project doesn't welcome change. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recording the current branch on each commit?
On 28/04/2014 10:09, Johan Herland wrote: On Mon, Apr 28, 2014 at 11:01 AM, Jeremy Mortonad...@game-point.net wrote: On 28/04/2014 07:45, Christian Couder wrote: Yes, it's possible. Yesterday, I sent the following patch: [RFC/PATCH 2/2] trailer: add examples to the documentation and it shows a commit-msg hook to do something like that: $ cat.git/hooks/commit-msgEOF #!/bin/sh git interpret-trailers --trim-empty --trailer git-version: \$(git describe) \$1 \$1.new mv \$1.new \$1 EOF $ chmod +x .git/hooks/commit-msg I think you just need to use the following if you want the branch instead of the git version: git interpret-trailers --trim-empty --trailer git-branch: \$(git name-rev --name-only HEAD) \$1 \$1.new It could even be simpler if there was an option (which has already been discussed) that made it possible to modify the file in place. This way one would not need the 'mv \$1.new \$1' command. This is certainly going in the right direction, but it's still implemented as a hook on a per-repo basis. Do you foresee a point in the future where these trailers could be added through simple one-liners in someone's global .gitconfig file? That's where I'd really like to get to. It's a hack, but it works surprisingly well in practice (assuming that you and your co-workers all agree that this is an acceptable approach): 1. Write the hook script and add it to your project (in a git-hooks subdir or something) 2. Add a post-checkout hook to install the first hook and the post-checkout hook itself into the user's .git/hooks/ dir. 3. Tell your co-workers to run the post-checkout hook script manually the first time. After that, the script should take care of updating itself and any hooks that you add to the project. ...Johan I don't understand why the co-workers need to run the post-checkout hook script manually the first time? -- Best regards, Jeremy Morton (Jez) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recording the current branch on each commit?
On 28/04/2014 10:01, Felipe Contreras wrote: Jeremy Morton wrote: On 27/04/2014 20:33, Johan Herland wrote: The problem is not really less tidy commit trees - by which I gather you mean history graphs that are non-linear. IMHO, the history graph should reflect parallel/branched development when that is useful. Blindly rebasing everything into a single line is IMHO just as bad as doing all your work directly on master and blindly running git pull between each of your own commits (which results in a lot of useless merges). The merge commits themselves are not the problem. Merge commits are a tool, and when used properly (to introduce topics to the master branch like described above) they are a good tool. When abused (like blindly running git pull and accepting useless merge bubbles) they create more problems than they solve. Sounds like the default behaviour of git pull might not be ideal if it easily causes these problems. It's not idea. Virtually everyone agrees with that, even Linus Torvalds, and we have the patches to fix it, but it's not going to change. The Git project doesn't welcome change. Well, you sure don't seem to. Why are there so many no-can-do people on this list? :-) -- Best regards, Jeremy Morton (Jez) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recording the current branch on each commit?
Jeremy Morton wrote: On 28/04/2014 10:01, Felipe Contreras wrote: Jeremy Morton wrote: On 27/04/2014 20:33, Johan Herland wrote: The problem is not really less tidy commit trees - by which I gather you mean history graphs that are non-linear. IMHO, the history graph should reflect parallel/branched development when that is useful. Blindly rebasing everything into a single line is IMHO just as bad as doing all your work directly on master and blindly running git pull between each of your own commits (which results in a lot of useless merges). The merge commits themselves are not the problem. Merge commits are a tool, and when used properly (to introduce topics to the master branch like described above) they are a good tool. When abused (like blindly running git pull and accepting useless merge bubbles) they create more problems than they solve. Sounds like the default behaviour of git pull might not be ideal if it easily causes these problems. It's not idea. Virtually everyone agrees with that, even Linus Torvalds, and we have the patches to fix it, but it's not going to change. The Git project doesn't welcome change. Well, you sure don't seem to. Why are there so many no-can-do people on this list? :-) I don't seem to what? I'm the one arguing for change, and I sent the patches to fix this default behavior. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recording the current branch on each commit?
On 28/04/2014 10:17, Felipe Contreras wrote: I don't seem to what? I'm the one arguing for change, and I sent the patches to fix this default behavior. Well maybe you should work on phrasing things better - you come across as quite negative. -- Best regards, Jeremy Morton (Jez) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recording the current branch on each commit?
On 04/28/2014 02:22 PM, Jeremy Morton wrote: On 28/04/2014 03:30, Sitaram Chamarty wrote: On 04/28/2014 01:03 AM, Johan Herland wrote: Yeah, sure. Author and Date (and Committer, for that matter) is just metadata, and the current branch name is simply just another kind of metadata. All of them are more-or-less free-form text fields, and off no they're not. In strictly controlled environments they form part of the audit record for the source code. Yes they can be faked (explicitly), but -- again in strictly controlled environments -- that can be limited to before it was first pushed. Why these specific headers as part of the audit record, though? Aren't you just arbitrarily defining them as part of the audit record? who did it and when did they do it are a fair bit more central to how did we get here (viz., the SHA1 of the top commit, if you will) than what branch was this commit born in (or similar). Here's an example from somewhere I worked (indirectly) in the late 90s. Nasty bug, easily fixable (a few characters to change). Customer group all p-ed off. Developer has access to the version control server. He changes something on the VC system to appear as if the bug never existed in the version of the code he shipped to whoever. As a result, the bug was deemed to have mysteriously appeared somewhere along the line. It didn't help that parts of the workflow were semi-manual, so he *did* have vague things to point at. I don't believe I can explain that any better or go into details without some risk, so if you don't agree then that's all there is to it. Suffice it to say I am strongly opposed to the idea, but as long as it's optional -- and for the right reasons (see my other email) -- I'd be OK. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recording the current branch on each commit?
Felipe Contreras felipe.contre...@gmail.com writes: Jeremy Morton wrote: Sounds like the default behaviour of git pull might not be ideal if it easily causes these problems. It's not idea. Virtually everyone agrees with that, even Linus Torvalds, and we have the patches to fix it, but it's not going to change. The Git project doesn't welcome change. I can think of a few other things that the Git project or actually pretty much everybody doesn't welcome. It becomes easier to actually change things when communicating in a less abrasive and destructive manner. At any rate, releases involve time plans and testing periods. Personally I think that the automerging behavior of git pull is one of the most stupid traps Git has available for beginning contributors to make a royal mess of their contributions. It's unbelievable that this has not been defused a decade ago already. But it hasn't, and such a change is no longer in a useful time frame for a 2.0 release. Unless one wants to push back the 2.0 release considerably for this alone. But then everybody will have a favorite pet peeve, some likely more justified, some less, that he wants to get into 2.0. I mean, I just sped up git-blame for serious use cases by a factor of 3 or so at least, and there will be _no_ API changes and user-visible consequences with that change. So what? If the thing has been important enough to get into 2.0, it has been important enough to push for it _timely_ so that it had a chance at considerable testing exposure. That's what has been done with the git push changes. They were put in timely, with quite a bit of warning about what will change and what people are supposed to be doing about it. Again: bad enough that it took as long as that to fix this insanely reckless default. The scale of the git-pull problem is small in comparison as it only messes up a single local branch instead of a whole set of upstream branches. -- David Kastrup -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recording the current branch on each commit?
Jeremy Morton ad...@game-point.net writes: On 28/04/2014 10:02, David Kastrup wrote: Jeremy Mortonad...@game-point.net writes: On 28/04/2014 09:32, Felipe Contreras wrote: some people to is to always merge with --no-ff, that way you see the branch name in the merge commit. But surely, it's recommended with Git that you try to avoid doing --no-ff merges to avoid commit noise? Nope. Different people have different needs, there's no recommendation. If anything, the recommendation is to do a ff merge, because that's the default. That's what I'm saying. With an ff merge, you don't get the merge commit message telling you the branch name. And I don't _want_ that branch name to be recorded. The whole point of a distributed version control system is that it's nobody else's business how I organize my work before submitting it. Well it would be optional, so obviously you wouldn't be forced to share the branch name. It's not like we're trying to pry in to your private development. It's a way of choosing to share what you may consider to be useful contextual information about the commit. But it isn't useful contextual information about the commit because it is tied to a particular repository. It is _totally_ useless information in a distributed development model. Why would or should anybody be concerned what private branches some submitter has developed his patches in? Why should anybody be concerned about what commit message some submitter has typed in for his commit? They could just read the source code to see what has changed, right? The commit message is an integral part of a commit. The contents of the commit message are not tied to a particular repository. The branch name, however, is. Because the commit message is a way for the submitter to try and make it easier for the people looking at the commit to understand what the commit is doing. The commit message is written for an audience and is independent of the repository. The branch name isn't. In the same way, a meaningful branch name may also make it easier for people looking at the commit to understand what it is doing, It is nobody's business how I name my branches. I can change the commit message using git commit --amend, but what should happen if I rename the branch a commit is on? And what nightmare should occur when doing git cherry-pick? What _is_ the originating branch of a cherry-pick? What _is_ the originating branch of a merge commit? Or even of a cherry-picked merge commit? or what part of the application it is affecting, or what group of commits it is a part of. If I have useful information to offer to the readers of a commit, it belongs in the commit message. Not in some involuntarily created and leaked piece of metadata specific to my workflow and repository that will be awfully hard to change after the fact. -- David Kastrup -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recording the current branch on each commit?
On Mon, Apr 28, 2014 at 12:03 PM, Sitaram Chamarty sitar...@gmail.com wrote: Johan Herland jo...@herland.net writes: Obviously, the feature would necessarily have to be optional, simply because Git would have to keep understanding the old commit object format for a LONG time (probably indefinitely), and there's nothing you can do to prevent others from creating old-style commit objects. Johan: I seem to have missed your previous email (fat-fingered something on my mail client I expect). Your **reasons** for making it optional are all wrong. People like me (and David) who are opposed to this run the risk that if the **format** were to officially change in some way or for some reason (like, say, if SHA1 is no longer in favour, or whatever), then this feature is foisted on us willy-nilly. That's not good. So, while I appreciate your point that it should be optional, please let's accept that in the end it should be optional because **not everyone likes it**! You may have missed more than just one previous email... I tried (but obviously failed) to make it clear from the start that I personally don't support this feature (although, as long as it's optional I'm mostly indifferent to it). Trying to steer the discussion towards a constructive end, I then argued that even IF we were to agree that this was a good change (and this thread CLEARLY demonstrates that we DO NOT agree), it would STILL be better to first implement this change within the confines of the existing object model, without making any changes to Git itself. Having done an initial implementation outside of the git core (which should be fairly straightforward with hooks + git-interpret-trailers), Jeremy would have gotten the feature he wanted (or at least a close approximation), and we could then observe if this feature became popular/useful enough to consider integrating it into core Git. So, the only constructive way forward (whether we like the feature or not) is for Jeremy (or someone else) to first implement it outside the Git core. THIS is my point, and I really, REALLY tried to explain it while AVOIDING the inevitable flamewar about what belongs in a commit object or not. It's not that I don't have an opinion on that subject; it's that everybody has their own opinion, and it's largely a philosophical discussion that boils down to peoples workflows, preferences, backgrounds, and whatnot. As such, it's perfect material for the flamewar we're currently observing... ...Johan -- Johan Herland, jo...@herland.net www.herland.net -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recording the current branch on each commit?
Jeremy Morton wrote: On 28/04/2014 10:17, Felipe Contreras wrote: I don't seem to what? I'm the one arguing for change, and I sent the patches to fix this default behavior. Well maybe you should work on phrasing things better - you come across as quite negative. What is the difference between a negative person and a realist, when what both say are the same and true? It's literally almost impossible to change an existing behavior in Git, including the default behavior of 'git pull`, even if basically everybody agrees the current behavior is wrong. That's just a fact. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recording the current branch on each commit?
Max Kirillov m...@max630.net writes: Obviously, the feature would necessarily have to be optional, simply because Git would have to keep understanding the old commit object format for a LONG time (probably indefinitely), and there's nothing you can do to prevent others from creating old-style commit objects. Doesn't git ignores unknown headers? I has been investigating this issue and it looked like it does. Could the API to add commit headers (which exists in sources) be added to cli, so users can create the branches, phases or whatever they feel useful? We had lengthy discussions in early 2010 [*1*]. The whole thread, at least the whole sub-thread that contains the focused message, is a required reading to understand where we stand with respect to extra headers in commit objects. Any additional information about the commit can be added you suggest is exactly the kind of thing we want to avoid, which made Linus say in an even older discussion [*2*]: No this random field could be used this random way crud, please. [References] *1* http://thread.gmane.org/gmane.comp.version-control.git/138848/focus=138892 *2* http://thread.gmane.org/gmane.comp.version-control.git/19126/focus=19149 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recording the current branch on each commit?
David Kastrup wrote: Felipe Contreras felipe.contre...@gmail.com writes: Jeremy Morton wrote: Sounds like the default behaviour of git pull might not be ideal if it easily causes these problems. It's not idea. Virtually everyone agrees with that, even Linus Torvalds, and we have the patches to fix it, but it's not going to change. The Git project doesn't welcome change. I can think of a few other things that the Git project or actually pretty much everybody doesn't welcome. It becomes easier to actually change things when communicating in a less abrasive and destructive manner. That would make sense if I was the only one with the itch. But I wasn't the only one, so anybody could take the patches and send them in a less abrasive maner. In fact I have been contacted a couple of times privately suggesting me to use a softer tone in order to get my patches applied, in every time I issue a challenge. You send the patches, and you follow up the discussion in whatever tone you see fit, if they get in, I'll accept I'm wrong and use softer tone in the future. The fact of the matter is that the tone doesn't matter, the patches don't get in because change is not welcome. Period. But it hasn't, and such a change is no longer in a useful time frame for a 2.0 release. I sent the last version of the series in Octoboer 2013, there was more than enough time to merge them, or somebody else with more political traction to pick and finish whatever changes where needed (none). Unless one wants to push back the 2.0 release considerably for this alone. Why does it need to be pushed back? Have you looked at the patches? If so, what is the risk that there will be any problem with them? I mean, I just sped up git-blame for serious use cases by a factor of 3 or so at least, and there will be _no_ API changes and user-visible consequences with that change. I bet this could get into 2.0, but the big patch has to be split into smaller patches in order for them to be reviewed properly, and maybe merge a few of them at a time. If the thing has been important enough to get into 2.0, it has been important enough to push for it _timely_ so that it had a chance at considerable testing exposure. Really? What important changes does 2.0 have? There's literally nothing of interest to most users, maybe push.default = simple, but that's it. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recording the current branch on each commit?
Jeremy Morton ad...@game-point.net writes: But surely, it's recommended with Git that you try to avoid doing --no-ff merges to avoid commit noise? That is a misconception, I am afraid, coming from two different camps. Some projects do not want any merges for whatever reason, not limited to --no-ff merges. They want linear history perhaps due to inertia from their CVS days. In mergy projects, where no such merge avesion exists, there still is a valid reason why you are told to avoid no-ff, but I do not think it is primarily because no-ff is bad. The real reason why people need no-ff to record the fact that the side branch was a separate development is because they rebase on top of the project's tip right before they push it out. If you do not do that last minute rebase, you do not have to do a no-ff, unless the project is so quiet and no other people are actively working on the codebase. And in such a case, no-ff would be very much justified. I do not fundamentally oppose if you want to add Done-as-part-of: frotz-topic at the end of the log message of each commit that belongs to the topic in your project (I personally wouldn't welcome such a convention in _this_ project, though). Christian's trailers series may serve as a building block for such a feature. But as we can see in the thread, many people view (including me) that the choice of branch name is a personal thing, irrelevant in the project-wide history, so even if you add a built-in support to make it easier for you to add such a trailer, it has to be something optional the projects explicitly must choose to use by flipping some toggle. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recording the current branch on each commit?
Felipe Contreras felipe.contre...@gmail.com wrote: David Kastrup wrote: It becomes easier to actually change things when communicating in a less abrasive and destructive manner. That would make sense if I was the only one with the itch. But I wasn't the only one, so anybody could take the patches and send them in a less abrasive maner. It's not anybody else's job to take your patches and drizzle them in the honey of respectable discourse. They're your patches, nobody else is going to champion them for you. The fact of the matter is that the tone doesn't matter, the patches don't get in because change is not welcome. Period. You neglect the possibility that your personal view of what git should be differs from other people's. One's views and values aren't correct just on the virtue of that person having them, and you are no different, Felipe. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recording the current branch on each commit?
James Denholm wrote: Felipe Contreras felipe.contre...@gmail.com wrote: David Kastrup wrote: It becomes easier to actually change things when communicating in a less abrasive and destructive manner. That would make sense if I was the only one with the itch. But I wasn't the only one, so anybody could take the patches and send them in a less abrasive maner. It's not anybody else's job to take your patches and drizzle them in the honey of respectable discourse. It's nobody's job to do anything. This a collaborative effort and in a collaborative effort everbody chimes in to do different things. It's not Jeff's patches, they are our patches, they are part of the project. And it's not unusual for multiple people working on a patch series; one person doing most of the work, another adding tests, another cleaning updocumentation. It's also no unheard of from a person picking up a patch series somebody else stopped working on. If a patch series is event considered to be merged upstream, that means it doesn't just benefit the person sending it (e.g. me), it benefits all Git users. So my patches where by the project and for the project. The fact of the matter is that the tone doesn't matter, the patches don't get in because change is not welcome. Period. You neglect the possibility that your personal view of what git should be differs from other people's. Except that in this case virtually everyone agreed the default was wrong. I already said that. Clarly you didn't read the relevant discussions where everyone, including Linus Torvalds, agreed. Did you? -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recording the current branch on each commit?
Felipe Contreras felipe.contre...@gmail.com writes: Except that in this case virtually everyone agreed the default was wrong. I already said that. Clarly you didn't read the relevant discussions where everyone, including Linus Torvalds, agreed. Did you? My recollection is that everybody agreed that the default was wrong. I do not think I saw everybody agreed the patch you are championing is the right solution to solve that problem. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recording the current branch on each commit?
Junio C Hamano wrote: Felipe Contreras felipe.contre...@gmail.com writes: Except that in this case virtually everyone agreed the default was wrong. I already said that. Clarly you didn't read the relevant discussions where everyone, including Linus Torvalds, agreed. Did you? My recollection is that everybody agreed that the default was wrong. I do not think I saw everybody agreed the patch you are championing is the right solution to solve that problem. I'm going to add the quote you removed: James Denholm wrote: You neglect the possibility that your personal view of what git should be differs from other people's. In this context James was talking about what Git should be. But the vast majority agree on this issue, so that's not what's preventing change. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recording the current branch on each commit?
Felipe Contreras felipe.contre...@gmail.com writes: In this context James was talking about what Git should be. But the vast majority agree on this issue, so that's not what's preventing change. Sorry, I saw take your patches from James and my patch from you in the context above that part, and somehow thought that the discussion was about the reason why a particular implementation that hit 'pu' once stalled and did not result in changing Git. I agree that recognition of the issue is not what prevents a change. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recording the current branch on each commit?
Junio C Hamano wrote: Felipe Contreras felipe.contre...@gmail.com writes: In this context James was talking about what Git should be. But the vast majority agree on this issue, so that's not what's preventing change. I agree that recognition of the issue is not what prevents a change. It's not just recognition of the issue, the solution is agreed too: change the default. The specifics of exactly how might not be. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recording the current branch on each commit?
Felipe Contreras felipe.contre...@gmail.com wrote: James Denholm wrote: It's not anybody else's job to take your patches and drizzle them in the honey of respectable discourse. It's nobody's job to do anything. This a collaborative effort and in a collaborative effort everbody chimes in to do different things. No, true, but my point was more related to that it's ones own task, perhaps being the better term than job, to debate the merits of one's own work when the merits are currently unknown to the rest of a community. It's not Jeff's patches, they are our patches, they are part of the project. And it's not unusual for multiple people working on a patch series; oneperson doing most of the work, another adding tests, another cleaning updocumentation. It's also no unheard of from a person picking up a patch series somebody else stopped working on. This, of course, would be the _other_ case where a proposal's merits are already known and accepted by the community. Different situation. Note that I here specify a proposal's merits are known and accepted, rather than the issue at hand. I'd be very, very surprised if there was even a few cases in human history where a community was able to collaboratively work, efficiently and successfully, on a proposal where the merits were still hotly discussed (barring, of course, exploratory works). If a patch series is event considered to be merged upstream, that means it doesn't just benefit the person sending it (e.g. me), it benefits all Git users. So my patches where by the project and for the project. And yes, of course, but you misinterpret my use of one's patches to describe ownership or who benefits from those patches. I merely discuss authorship and seek not to imply anything more. The fact of the matter is that the tone doesn't matter, the patches don't get in because change is not welcome. Period. You neglect the possibility that your personal view of what git should be differs from other people's. Except that in this case virtually everyone agreed the default was wrong. I already said that. Clarly you didn't read the relevant discussions where everyone, including Linus Torvalds, agreed. Did you? I'm talking about the general case, not a _specific_ patch or set thereof authored by you or any one person. Again, though, recall that even if a community has agreed that the current state is non-ideal, that doesn't mean that they agree that a _specific proposal_ is the right one. If A and B agree that they are starving to death, and B proposes they engage in hunting to resolve this, A might disagree because he'd rather just go across the street and buy a loaf of bread. Although as I write this it seems Junio has described this exact thing in a following mail, and on the following debate: A patch relates to more than a personal view of what a project shouldn't be. Even if it's solving an acknowledged problem, it by it's nature relates to a view of what the solution should be. Ergo, in the specific case, your view of what the solution should have been did not match the community's view of the same, even if the overall problem was acknowledged by the entire community. The default may be wrong, you and I might agree that the default is wrong, Junio and Torvalds and RMS and The Queen of England might all agree that the default is wrong... But if we all live across from a bread shop, it's going to be a difficult task for you to convince us to go hunting. Sincerely and analogically yours, James Denholm. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recording the current branch on each commit?
James Denholm wrote: Felipe Contreras felipe.contre...@gmail.com wrote: James Denholm wrote: It's not anybody else's job to take your patches and drizzle them in the honey of respectable discourse. It's nobody's job to do anything. This a collaborative effort and in a collaborative effort everbody chimes in to do different things. No, true, but my point was more related to that it's ones own task, It's still the same thing. Nobody gets assigned any tasks; people choose their own tasks, and they might choose tasks that other people were doing. It's not Jeff's patches, they are our patches, they are part of the project. And it's not unusual for multiple people working on a patch series; oneperson doing most of the work, another adding tests, another cleaning updocumentation. It's also no unheard of from a person picking up a patch series somebody else stopped working on. This, of course, would be the _other_ case where a proposal's merits are already known and accepted by the community. No. John might have sent a patch series X, and maybe he didn't explain correctly how it would benefit the project. Later on Mark finds out how those patches would be useful for himself and takes upon himself to get them merged, so he cleans them up and send an updated version with a clear explanation of how they would be useful. It's still the same proposal X, but a different person and a different strategy to get them merged. In other words, the fact that the community has not yet accepted the merits of an approach doesn't mean that another person cannot champion it. The default may be wrong, you and I might agree that the default is wrong, Junio and Torvalds and RMS and The Queen of England might all agree that the default is wrong... But if we all live across from a bread shop, it's going to be a difficult task for you to convince us to go hunting. It doesn't matter if you want to go hunting and I want to buy bread, either one of those is better than starving to death. In the Git project though, we choose to starve to death. Neither were my patches picked, nor did anybody else step up with a different proposal, we just did nothing, which is what we always do. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recording the current branch on each commit?
- Ursprungligt meddelande - Från: Jeremy Morton ad...@game-point.net Till: git@vger.kernel.org Skickat: söndag, 27 apr 2014 1:56:47 Ämne: Recording the current branch on each commit? Currently, git records a checksum, author, commit date/time, and commit message with every commit (as get be seen from 'git log'). I think it would be useful if, along with the Author and Date, git recorded the name of the current branch on each commit. The branch name can provide useful contextual information. For instance, let's say I'm developing a suite of games. If the commit message says Added basic options dialog, it might be useful to see that the branch name is pacman-minigame indicating that the commit pertains to the options dialog in the Pacman minigame. Basically, I'm saying that well-named branches can and do carry useful contextual information that oughtn't to be thrown away. Currently, when you delete that branch, you lose the branch name altogether. So what do you think? Would it be good to have a patch to add this feature? Branch names are usually poorly named, so often you don't lose much. One way some people to is to always merge with --no-ff, that way you see the branch name in the merge commit. A very popular way of tracking context is to add some id, such as a bugzilla issue number, to the header or footer of the commit message. Often a branch contains many issues, but the branch itself isn't very interesting. Tools like gitblit, gitweb, gerrit etc can easily be configured to link to the issue using a regular expression. -- robin -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recording the current branch on each commit?
On Sun, Apr 27, 2014 at 1:56 AM, Jeremy Morton ad...@game-point.net wrote: Currently, git records a checksum, author, commit date/time, and commit message with every commit (as get be seen from 'git log'). I think it would be useful if, along with the Author and Date, git recorded the name of the current branch on each commit. This has been discussed multiple times in the past. One example here: http://thread.gmane.org/gmane.comp.version-control.git/229422 I believe the current conclusion (if any) is that encoding such information as a _structural_ part of the commit object is not useful. See the old thread(s) for the actual pro/con arguments. That said, you are of course free to add this information to your own commit messages, by appending something like Made-on-branch: frotz. In a company setting, you can even create a commit message template or (prepare-)commit-msg hook to have this line created automatically for you and your co-workers. You could even append such information retroactively to existing commits with git notes. There is also the current interpret-trailers effort by Christian Couder [1] that should be useful in creating and managing such lines. [1]: http://thread.gmane.org/gmane.comp.version-control.git/245874 The branch name can provide useful contextual information. For instance, let's say I'm developing a suite of games. If the commit message says Added basic options dialog, it might be useful to see that the branch name is pacman-minigame indicating that the commit pertains to the options dialog in the Pacman minigame. In that partcular case, ISTM that the context (pacman-minigame) would actually be better preserved elsewhere. E.g. the commits touch files in a particular minigames/pacman subdir, or you prefix the context in the commit message (pacman-minigame: Added basic options dialog). Also, such a topic branch is often tied to a specific issue in some bug/issue tracker, and it would in any case be natural to mention the bug/issue ID in the commit message, at which point the tracker can provide more context and discussion. Basically, I'm saying that well-named branches can and do carry useful contextual information that oughtn't to be thrown away. Currently, when you delete that branch, you lose the branch name altogether. Some would argue that branches are not always well-named... But anyway, if the branch ends up getting merged to the mainline, the merge commit defaults to a message like Merge branch 'pacman-minigame'. So what do you think? Would it be good to have a patch to add this feature? One is free to try, of course, but I wouldn't get my hopes up for a patch that changes the fundamental format of the commit object to include something that many users/workflows would consider to be pure cruft. If you still believe that this is useful enough to warrant a change to the commit object format, it is probably better to start off putting the information in the commit message (as described above), and provide some tools that demonstrate the added value of this information. If that is successful and gains momentum, the git community can certainly reconsider whether it makes sense to fold it into a more formalized part of the commit object. ...Johan -- Johan Herland, jo...@herland.net www.herland.net -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recording the current branch on each commit?
On 27/04/2014 09:51, Robin Rosenberg wrote: Currently, git records a checksum, author, commit date/time, and commit message with every commit (as get be seen from 'git log'). I think it would be useful if, along with the Author and Date, git recorded the name of the current branch on each commit. The branch name can provide useful contextual information. For instance, let's say I'm developing a suite of games. If the commit message says Added basic options dialog, it might be useful to see that the branch name is pacman-minigame indicating that the commit pertains to the options dialog in the Pacman minigame. Basically, I'm saying that well-named branches can and do carry useful contextual information that oughtn't to be thrown away. Currently, when you delete that branch, you lose the branch name altogether. So what do you think? Would it be good to have a patch to add this feature? Branch names are usually poorly named, so often you don't lose much. One way Speak for yourself - I give my branches useful names. :-) I definitely feel that I am often losing useful contextual information by throwing away the branch name. some people to is to always merge with --no-ff, that way you see the branch name in the merge commit. But surely, it's recommended with Git that you try to avoid doing --no-ff merges to avoid commit noise? Also, it is a lot more hassle (and no doubt, CPU cycles) to track down where a branch was merged to try and figure out which branch name a commit pertained to, not to mention the fact that the commit could've been moved since. Nothing short of tagging the commit with the branch name when the commit is made will definitely record the branch name at the time of committing. A very popular way of tracking context is to add some id, such as a bugzilla issue number, to the header or footer of the commit message. Often a branch contains many issues, but the branch itself isn't very interesting. Tools like gitblit, gitweb, gerrit etc can easily be configured to link to the issue using a regular expression. Yes, and I have done this kind of thing in the past. However you really don't want to put the bug# on every single commit pertaining to that bug; you have to go to the effort of looking the bug# up every time, you'll sometimes forget, and besides it takes up space that could be used for a commit message. As short commit messages are valued in Git, it's particularly bad to waste space this way. Much better would be to include the bug# as part of the branch name, and then if you record the branch name upon checkin you always get a reference to the bug#. Also, you don't always have something you can link a commit to in an issue tracker. You may just be implementing a feature that has been agreed upon, independently of any such tracker. In that case, there's no bug# to link to. -- Best regards, Jeremy Morton (Jez) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recording the current branch on each commit?
On Sun, Apr 27, 2014 at 7:38 PM, Jeremy Morton ad...@game-point.net wrote: On 27/04/2014 10:09, Johan Herland wrote: On Sun, Apr 27, 2014 at 1:56 AM, Jeremy Mortonad...@game-point.net wrote: Currently, git records a checksum, author, commit date/time, and commit message with every commit (as get be seen from 'git log'). I think it would be useful if, along with the Author and Date, git recorded the name of the current branch on each commit. This has been discussed multiple times in the past. One example here: http://thread.gmane.org/gmane.comp.version-control.git/229422 I believe the current conclusion (if any) is that encoding such information as a _structural_ part of the commit object is not useful. See the old thread(s) for the actual pro/con arguments. As far as I can tell from that discussion, the general opposition to encoding the branch name as a structural part of the commit object is that, for some people's workflows, it would be unhelpful and/or misleading. Well fair enough then - why don't we make it a setting that is off by default, and can easily be switched on? That way the people for whom tagging the branch name would be useful have a very easy way to switch it on. Obviously, the feature would necessarily have to be optional, simply because Git would have to keep understanding the old commit object format for a LONG time (probably indefinitely), and there's nothing you can do to prevent others from creating old-style commit objects. Which brings us to another big con at this point: The cost of changing the commit object format. One can argue for or against a new commit object format, but the simple truth at this point is that changing the structure of the commit object is expensive. Even if we were all in agreement about the change (and so far we are not), there are multiple Git implementations (libgit2, jgit, dulwich, etc.) that would all have to learn the new commit object, not to mention that bumping core.repositoryformatversion would probably make your git repo incompatible with a huge number of existing deployments for the foreseeable future. Therefore, the most pragmatic and constructive thing to do at this point, is IMHO to work within the confines of the existing commit object structure. I actually believe using commit message trailers like Made-on-branch: frotz in addition to some helpful infrastructure (hooks, templates, git-interpret-trailers, etc.) should get you pretty much exactly what you want. And if this feature turns out to be extremely useful for a lot of users, we can certainly consider changing the commit object format in the future. I know that for the workflows I personally have used in the past, such tagging would be very useful. Quite often I have been looking through the Git log and wondered what feature a commit was part of, because I have feature branches. Just knowing that branch name would be really useful, but the branch has since been deleted... and in the case of a ff-merge (which I thought was recommended in Git if possible), the branch name is completely gone. True. The branch name is - for better or worse - simply not considered very important by Git, and a Git commit is simply not considered (by Git at least) to be part of or otherwise belong to any branch. Instead the commit history/graph is what Git considers important, and the branch names are really just more-or-less ephemeral pointers into that graph. AFAIK, recording the current branch name in commits was not considered to the worth including in Linus' original design, and since then it seems to only have come up a few times on the mailing list. This is quite central to Git's design, and changing it at this point should not be done lightly. IINM, Mercurial does this differently, so that may be a better fit for the workflows where keeping track of branch names is very important. That said, you are of course free to add this information to your own commit messages, by appending something like Made-on-branch: frotz. In a company setting, you can even create a commit message template or (prepare-)commit-msg hook to have this line created automatically for you and your co-workers. You could even append such information retroactively to existing commits with git notes. There is also the current interpret-trailers effort by Christian Couder [1] that should be useful in creating and managing such lines. [1]: http://thread.gmane.org/gmane.comp.version-control.git/245874 Well I guess that's another way of doing it. So, why aren't Author and Date trailers? They don't seem any more fundamental to me than branch name. I mean the only checkin information you really *need* is the checksum, and commit's parents. The Author and Date are just extra pieces of information you might find useful sometimes, right? A bit like some people might find branch checkin name useful sometimes...? Yeah, sure. Author and Date (and Committer, for that matter) is just
Re: Recording the current branch on each commit?
On 27/04/2014 20:33, Johan Herland wrote: On Sun, Apr 27, 2014 at 7:38 PM, Jeremy Mortonad...@game-point.net wrote: On 27/04/2014 10:09, Johan Herland wrote: As far as I can tell from that discussion, the general opposition to encoding the branch name as a structural part of the commit object is that, for some people's workflows, it would be unhelpful and/or misleading. Well fair enough then - why don't we make it a setting that is off by default, and can easily be switched on? That way the people for whom tagging the branch name would be useful have a very easy way to switch it on. Therefore, the most pragmatic and constructive thing to do at this point, is IMHO to work within the confines of the existing commit object structure. I actually believe using commit message trailers like Made-on-branch: frotz in addition to some helpful infrastructure (hooks, templates, git-interpret-trailers, etc.) should get you pretty much exactly what you want. And if this feature turns out to be extremely useful for a lot of users, we can certainly consider changing the commit object format in the future. OK, fair enough. So I guess what I'd like to see, then, is good built-in functionality in Git for these commit message trailers, so that they are very easy to turn on. I'd like to be able to tell co-developers to add a one-liner to their git config file rather than some post-commit script. I know that for the workflows I personally have used in the past, such tagging would be very useful. Quite often I have been looking through the Git log and wondered what feature a commit was part of, because I have feature branches. Just knowing that branch name would be really useful, but the branch has since been deleted... and in the case of a ff-merge (which I thought was recommended in Git if possible), the branch name is completely gone. True. The branch name is - for better or worse - simply not considered very important by Git, and a Git commit is simply not considered (by Git at least) to be part of or otherwise belong to any branch. Please understand that I know this full well. :-) I'm saying that the 'ephemeral' pointers' names are, in themselves, useful - if, like me, you give them meaningful names. What I'm proposing is pretty much an automatic tagging (somehow...) of each commit with the current branch name (if one is available); information that carries roughly the same weight as the commit message. It could be crap, but equally it could be very useful, in some workflows. I think most of us can agree on that. seems to only have come up a few times on the mailing list. This is But it has come up more than once, which would seem to indicate that I'm not the only one with this request. ;-) IINM, Mercurial does this differently, so that may be a better fit for If I'm Not Mistaken - I had to look that one up. the workflows where keeping track of branch names is very important. Nah, I had a look at Mercurial and I think I prefer Git - this branch name thing is just my one bugbear. I definitely prefer Git's concept of a staging area rather than just committing all changes. To do that in Mercurial you have to use mq and all the different (IMHO unintuative) commands that entails, and if you accidentally mq commit then you screw everything up. :-) Mercurial also discourages history rewriting (ie. cleaning up of messy commits), which Git doesn't. I prefer Git's approach here too. Yeah, sure. Author and Date (and Committer, for that matter) is just metadata, and the current branch name is simply just another kind of metadata. All of them are more-or-less free-form text fields, and off the top of my head, I can't really say that if we were to design Git from scratch today, they wouldn't all become optional trailers (or headers, or what-have-you). However, we're not designing Git from scratch, and we have to work with what is already there... Fair point. The branch name can provide useful contextual information. For instance, let's say I'm developing a suite of games. If the commit message says Added basic options dialog, it might be useful to see that the branch name is pacman-minigame indicating that the commit pertains to the options dialog in the Pacman minigame. In that partcular case, ISTM that the context (pacman-minigame) would actually be better preserved elsewhere. E.g. the commits touch files in a particular minigames/pacman subdir, or you prefix the context in the commit message (pacman-minigame: Added basic options dialog). Also, such a topic branch is often tied to a specific Again, this is a pain because you have to remember to manually tag every commit message with pacman-minigame, and it takes up precious space in the (already short) commit message. Yes, which is why I advise you to look at commit message templates, hooks, and interpret-trailers to see if you can find a way to automate this for you and your co-workers. What I'd like to
Re: Recording the current branch on each commit?
I'm skipping a lot of the discussion here, sorry about that, but on one particular note: Jeremy Morton ad...@game-point.net wrote: (...) and besides it takes up space that could be used for a commit message. As short commit messages are valued in Git, it's particularly bad to waste space this way. Not really. While different groups will have different values, the greater git community seems to prefer short _first lines_, of fifty chars or less, while the _body_ should be as verbose as it needs to be (but not more than). Ergo, while the first line shouldn't contain a swath of metadata, the body can easily. A particularly good example of this is almost every commit to the git project itself - there areSigned-of-by lines and such everywhere in the logs. Also, you don't always have something you can link a commit to in an issue tracker. You may just be implementing a feature that has been agreed upon, independently of any such tracker. In that case, there's no bug# to link to. In which case, refer to whatever system you use. If you aren't using a ticketing system, have the line Relates-to: Water cooler conversation with Bob on July 28th or whatever the patches relate to. (Arguably, though, the better solution is to use a ticketing system, or anything that allows discussion to be easily referenced.) Regards, James Denholm. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recording the current branch on each commit?
On 27/04/2014 22:40, James Denholm wrote: Also, you don't always have something you can link a commit to in an issue tracker. You may just be implementing a feature that has been agreed upon, independently of any such tracker. In that case, there's no bug# to link to. In which case, refer to whatever system you use. If you aren't using a ticketing system, have the line Relates-to: Water cooler conversation with Bob on July 28th or whatever the patches relate to. (Arguably, though, the better solution is to use a ticketing system, or anything that allows discussion to be easily referenced.) Well, as I said elsewhere in this discussion, Git should provide that functionality built-in, IMHO. It would be good to be able to set a one-liner in my .gitconfig to tag each commit with a branch checked into trailer. -- Best regards, Jeremy Morton (Jez) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recording the current branch on each commit?
Jeremy Morton ad...@game-point.net wrote: On 27/04/2014 22:40, James Denholm wrote: Also, you don't always have something you can link a commit to in an issue tracker. You may just be implementing a feature that has been agreed upon, independently of any such tracker. In that case, there's no bug# to link to. In which case, refer to whatever system you use. If you aren't using a ticketing system, have the line Relates-to: Water cooler conversation with Bob on July 28th or whatever the patches relate to. (Arguably, though, the better solution is to use a ticketing system, or anything that allows discussion to be easily referenced.) Well, as I said elsewhere in this discussion, Git should provide that functionality built-in, IMHO. It would be good to be able to set a one-liner in my .gitconfig to tag each commit with a branch checked into trailer. In that case, write something onto your post-commit hook and the functionality would be achieved. A relates-to line doesn't need a change to the structure of git commits. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recording the current branch on each commit?
On Sun, Apr 27, 2014 at 10:55 PM, Jeremy Morton ad...@game-point.net wrote: On 27/04/2014 20:33, Johan Herland wrote: On Sun, Apr 27, 2014 at 7:38 PM, Jeremy Mortonad...@game-point.net wrote: On 27/04/2014 10:09, Johan Herland wrote: As far as I can tell from that discussion, the general opposition to encoding the branch name as a structural part of the commit object is that, for some people's workflows, it would be unhelpful and/or misleading. Well fair enough then - why don't we make it a setting that is off by default, and can easily be switched on? That way the people for whom tagging the branch name would be useful have a very easy way to switch it on. Therefore, the most pragmatic and constructive thing to do at this point, is IMHO to work within the confines of the existing commit object structure. I actually believe using commit message trailers like Made-on-branch: frotz in addition to some helpful infrastructure (hooks, templates, git-interpret-trailers, etc.) should get you pretty much exactly what you want. And if this feature turns out to be extremely useful for a lot of users, we can certainly consider changing the commit object format in the future. OK, fair enough. So I guess what I'd like to see, then, is good built-in functionality in Git for these commit message trailers, so that they are very easy to turn on. I'd like to be able to tell co-developers to add a one-liner to their git config file rather than some post-commit script. I think this is what the interpret-trailers effort is about. Unfortunately I have not followed it closely enough to say if your use case is already covered by Christian's (CCed) work. Christian: With your current patch series, is it possible for Jeremy to configure interpret-trailers to automatically append a Made-on-branch: current_branch trailer whenever he creates a commit? [...] What I'd like to see, then, is this trailer functionality built in to Git so that a very minimal amount of setup is needed to get everybody using it. We're basically talking about hijacking the commit messages and tacking on information that they weren't really intended to hold (ie. stuff the developer hasn't manually typed in as a commit message), because of the limitation of the Git commit format. In hindsight, I guess it would've been better to have the Git commit format be more flexible in terms of what headers it allows, so that new headers could easily be added and some headers could be optional. Which - if you squint at it a little - is sort of what the interpret-trailers effort does. AFAIK, it (combined with hooks) allows you to configure a set of optional s/headers/trailers/ and the policies surrounding those. Only if it's a non-ff merge, which results in less tidy commit trees, and hence is often recommended against. Not at all. If you're developing a series of commits with a common purpose (a.k.a. a topic branch) I would very much argue for non-ff-merging this, _exactly_ because the merge commit allows you to introduce the entire topic as a single entity. The merge commit message (in addition to containing the branch name) is also the natural place to describe more general things about the topic as a whole - sort of like the cover letter to a patch series. Would you recommend that every single commit be made in a branch that gets merged into master, then? So, no direct commits to master? There are a lot of variables here, and it really comes down to your (team's) preferred workflow. Different teams/people prefer different workflows, and git's toolbox allows a wide (probably the widest among any VCS) variety of workflows to be expressed. So I really cannot make any sweeping/simple recommendations that will apply to all cases. Although I prefer collecting related commits on a topic branch that are then (non-ff) merged into master, I also see the value of performing a quick single-commit bugfix directly on master. In the latter case, the commit should obviously be self-sufficient and self-explanatory. However, once your work start spanning more than a few commits, you should really think about putting it on a separate branch, where it can be (re)organized in a way that is logical and reviewable (interactive rebase FTW). When I think about it, this might only apply to centralized workflows where team members (typically co-workers) push their own work to a shared repository/branch. As a counterexample: in git.git, pretty much every change (whether it consists of a single patch, or a series of patches) gets its own $who/$what branch in Junio's tree, and are then merged to 'pu'. When deemed worthy, they are merged to 'next' and - later - to 'master'. So here, even single-commit changes get their own branch and subsequent merge commit. Likewise, with GitHub's pull-request workflow, you make changes on a branch in one repo, and then request that branch to be pulled (i.e. merged) into another repo, regardless of whether
Re: Recording the current branch on each commit?
On 04/28/2014 01:03 AM, Johan Herland wrote: On Sun, Apr 27, 2014 at 7:38 PM, Jeremy Morton ad...@game-point.net wrote: On 27/04/2014 10:09, Johan Herland wrote: On Sun, Apr 27, 2014 at 1:56 AM, Jeremy Mortonad...@game-point.net wrote: Currently, git records a checksum, author, commit date/time, and commit message with every commit (as get be seen from 'git log'). I think it would be useful if, along with the Author and Date, git recorded the name of the current branch on each commit. This has been discussed multiple times in the past. One example here: http://thread.gmane.org/gmane.comp.version-control.git/229422 I believe the current conclusion (if any) is that encoding such information as a _structural_ part of the commit object is not useful. See the old thread(s) for the actual pro/con arguments. As far as I can tell from that discussion, the general opposition to encoding the branch name as a structural part of the commit object is that, for some people's workflows, it would be unhelpful and/or misleading. Well fair enough then - why don't we make it a setting that is off by default, and can easily be switched on? That way the people for whom tagging the branch name would be useful have a very easy way to switch it on. Obviously, the feature would necessarily have to be optional, simply because Git would have to keep understanding the old commit object format for a LONG time (probably indefinitely), and there's nothing you can do to prevent others from creating old-style commit objects. Which brings us to another big con at this point: The cost of changing the commit object format. One can argue for or against a new commit object format, but the simple truth at this point is that changing the structure of the commit object is expensive. Even if we were all in agreement about the change (and so far we are not), there are multiple Git implementations (libgit2, jgit, dulwich, etc.) that would all have to learn the new commit object, not to mention that bumping core.repositoryformatversion would probably make your git repo incompatible with a huge number of existing deployments for the foreseeable future. Therefore, the most pragmatic and constructive thing to do at this point, is IMHO to work within the confines of the existing commit object structure. I actually believe using commit message trailers like Made-on-branch: frotz in addition to some helpful infrastructure (hooks, templates, git-interpret-trailers, etc.) should get you pretty much exactly what you want. And if this feature turns out to be extremely useful for a lot of users, we can certainly consider changing the commit object format in the future. I know that for the workflows I personally have used in the past, such tagging would be very useful. Quite often I have been looking through the Git log and wondered what feature a commit was part of, because I have feature branches. Just knowing that branch name would be really useful, but the branch has since been deleted... and in the case of a ff-merge (which I thought was recommended in Git if possible), the branch name is completely gone. True. The branch name is - for better or worse - simply not considered very important by Git, and a Git commit is simply not considered (by Git at least) to be part of or otherwise belong to any branch. Instead the commit history/graph is what Git considers important, and the branch names are really just more-or-less ephemeral pointers into that graph. AFAIK, recording the current branch name in commits was not considered to the worth including in Linus' original design, and since then it seems to only have come up a few times on the mailing list. This is quite central to Git's design, and changing it at this point should not be done lightly. IINM, Mercurial does this differently, so that may be a better fit for the workflows where keeping track of branch names is very important. That said, you are of course free to add this information to your own commit messages, by appending something like Made-on-branch: frotz. In a company setting, you can even create a commit message template or (prepare-)commit-msg hook to have this line created automatically for you and your co-workers. You could even append such information retroactively to existing commits with git notes. There is also the current interpret-trailers effort by Christian Couder [1] that should be useful in creating and managing such lines. [1]: http://thread.gmane.org/gmane.comp.version-control.git/245874 Well I guess that's another way of doing it. So, why aren't Author and Date trailers? They don't seem any more fundamental to me than branch name. I mean the only checkin information you really *need* is the checksum, and commit's parents. The Author and Date are just extra pieces of information you might find useful sometimes, right? A bit like some people might find branch checkin name useful sometimes...? Yeah, sure. Author and Date (and Committer, for that
Recording the current branch on each commit?
Currently, git records a checksum, author, commit date/time, and commit message with every commit (as get be seen from 'git log'). I think it would be useful if, along with the Author and Date, git recorded the name of the current branch on each commit. The branch name can provide useful contextual information. For instance, let's say I'm developing a suite of games. If the commit message says Added basic options dialog, it might be useful to see that the branch name is pacman-minigame indicating that the commit pertains to the options dialog in the Pacman minigame. Basically, I'm saying that well-named branches can and do carry useful contextual information that oughtn't to be thrown away. Currently, when you delete that branch, you lose the branch name altogether. So what do you think? Would it be good to have a patch to add this feature? -- Best regards, Jeremy Morton (Jez) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
