{"thread":{"id":"43636","subject":"Re: Feature request: git-pull -e/--edit","startedAt":"2006-11-20T13:42:13Z","lastAt":"2006-11-21T09:19:59Z","messageCount":5,"participants":["Horst H. von Brand","Eran Tromer","Johannes Schindelin","Petr Baudis"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"298121","messageId":"4561B0B5.1020305@tromer.org","threadId":"43636","inReplyTo":"7v8xi67qhq.fsf@assigned-by-dhcp.cox.net","subject":"Re: Feature request: git-pull -e/--edit","fromName":"Eran Tromer","fromEmail":"git2eran@tromer.org","sentAt":"2006-11-20T13:42:13Z","receivedAt":"2006-11-20T13:42:13Z","isPatch":false,"sender":{"key":"git2eran@tromer.org","avatar":null},"body":"On 2006-11-20 05:21, Junio C Hamano wrote:\n> linux@horizon.com writes:\n\n>> (Indeed, it might be nice to come up with a way of including a piece of\n>> the \"please pull\" e-mail, similar to the way that git-applypatch works.)\n> \n> That is a lot more relevant example. For example, I could\n> imagine that Linus coming up with a wrapper that is fed a series\n> of e-mails and:\n> \n[snip]\n> - otherwise annotate the commit message with the explanation\n> of the series taken from the pull request message.\n[snip]\n> - People can say \"git pull -m 'I am doing this merge for such\n> and such reason' $URL $branch\" to _include_ that message in\n> the resulting merge commit;\n> \n> - The same can be said about \"git merge -m 'comment' $branch\".\n\n\nWhat about fast forwards? Do you get to record the explanation for the\nseries only if the guy you pulled from didn't bother to do a rebase?\nThat's broken.\n\nLet's face it, the merge commits generated when pulling have two\ncompletely independent uses:\n1. They're technically necessary for joining DAG nodes that don't all\n lie on one path.\n2. They're useful as a record of workflow and a place to put comments.\n\nThe two uses are nearly independent.\nConsider the following silly DAG.\n\n A------------F master\n \\ /\n B--C--D--E\n\nYes, E and F have identical trees. But it's actually *very useful*, if\nthe commit message at F says \"merged branch foo containing experimental\nbar from quux\". And it shows up nicely when looking at gitk.\n\nOf course, you could just fast-forward instead:\n\n A--B--C--D--E master\n\nbut then you lose a meaningful and useful part of the historical record.\n\nThere are the obvious bad consequences if you make this the default,\nbut how about adding a --force-commit option to merge and pull?\n\nYou'd need to educate users on how to use this responsibly to avoid\nnoise, but that's not any different from existing stuff like rebase and\nrevert. Most users won't even know it exists.\n\nAnd to answer Linus: yes, it's expected that only non-leaf developers\nwill use --force-commit on regular basis, but that's not because\nmaintainers are technically special in any way. It's just because\nmaintainers have something useful to say (\"someone's private topic\nbranch, starting at A and ending at E, has just been accepted into my\nall-important public repo and here's why\"). Anyone else can do the same\nif he feels likewise.\n\n"},{"id":"296158","messageId":"200611201709.kAKH9or1012062@laptop13.inf.utfsm.cl","threadId":"43636","inReplyTo":"git2eran@tromer.org","subject":"Re: Feature request: git-pull -e/--edit","fromName":"Horst H. von Brand","fromEmail":"vonbrand@inf.utfsm.cl","sentAt":"2006-11-20T17:09:50Z","receivedAt":"2006-11-20T17:09:50Z","isPatch":false,"sender":{"key":"vonbrand@inf.utfsm.cl","avatar":"https://avatars.githubusercontent.com/u/211384?v=4"},"body":"Eran Tromer wrote:\n\n[...]\n\n> What about fast forwards? Do you get to record the explanation for the\n> series only if the guy you pulled from didn't bother to do a rebase?\n> That's broken.\n> \n> Let's face it, the merge commits generated when pulling have two\n> completely independent uses:\n> 1. They're technically necessary for joining DAG nodes that don't all\n> lie on one path.\n> 2. They're useful as a record of workflow and a place to put comments.\n> \n> The two uses are nearly independent.\n> Consider the following silly DAG.\n> \n> A------------F master\n> \\ /\n> B--C--D--E\n> \n> Yes, E and F have identical trees. But it's actually *very useful*, if\n> the commit message at F says \"merged branch foo containing experimental\n> bar from quux\". And it shows up nicely when looking at gitk.\n\nI don't see the usefulness of this. \n\n> Of course, you could just fast-forward instead:\n> \n> A--B--C--D--E master\n\nYep.\n\n> but then you lose a meaningful and useful part of the historical record.\n\nAnd if quux merges back, she gets the same plus a new merge node, and...\nLinus told everybody (quite forcefully, I might add) that this is not\nacceptable for distributed development.\n\n> There are the obvious bad consequences if you make this the default,\n> but how about adding a --force-commit option to merge and pull?\n\nFast forward is fast forward. Merge is when /independent/ changes are\nintegrated into one.\n\n> You'd need to educate users on how to use this responsibly\n\nLooks like you've never met real users ;-)\n\n> to avoid\n> noise, but that's not any different from existing stuff like rebase and\n> revert. Most users won't even know it exists.\n\n> And to answer Linus: yes, it's expected that only non-leaf developers\n> will use --force-commit on regular basis, but that's not because\n> maintainers are technically special in any way. It's just because\n> maintainers have something useful to say (\"someone's private topic\n> branch, starting at A and ending at E, has just been accepted into my\n> all-important public repo and here's why\"). Anyone else can do the same\n> if he feels likewise.\n\nBut the individual changes will presumably reflect said someone's\nauthorship. If they are interleaved with stuff by others or not doesn't\nmake much (development) sense. Yes, it might be interesting for a software\nhistorian, but that's not git's main audience in the first place.\n-- \nDr. Horst H. von Brand User #22616 counter.li.org\nDepartamento de Informatica Fono: +56 32 2654431\nUniversidad Tecnica Federico Santa Maria +56 32 2654239\n"},{"id":"297561","messageId":"20061120181159.GB7201@pasky.or.cz","threadId":"43636","inReplyTo":"200611201709.kAKH9or1012062@laptop13.inf.utfsm.cl","subject":"Re: Feature request: git-pull -e/--edit","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-11-20T18:11:59Z","receivedAt":"2006-11-20T18:11:59Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Mon, Nov 20, 2006 at 06:09:50PM CET, Horst H. von Brand wrote:\n> Eran Tromer wrote:\n> > A------------F master\n> > \\ /\n> > B--C--D--E\n..snip..\n> And if quux merges back, she gets the same plus a new merge node, and...\n> Linus told everybody (quite forcefully, I might add) that this is not\n> acceptable for distributed development.\n\nWrong, if quux merges back and does not do the same \"force commit\"\nfast-forward (why would it, anyway - OP clearly said it's only if you\n_want_ to make it explicit), quux won't get another merge but end up\nwith F as well. It all converges back nicely.\n\nI can see how it could be useful.\n\n> > You'd need to educate users on how to use this responsibly\n> \n> Looks like you've never met real users ;-)\n\nYes, that is a real problem. ;-) But not adding features because users\ncould use them irresponsibly doesn't get you too far.\n\n> > And to answer Linus: yes, it's expected that only non-leaf developers\n> > will use --force-commit on regular basis, but that's not because\n> > maintainers are technically special in any way. It's just because\n> > maintainers have something useful to say (\"someone's private topic\n> > branch, starting at A and ending at E, has just been accepted into my\n> > all-important public repo and here's why\"). Anyone else can do the same\n> > if he feels likewise.\n> \n> But the individual changes will presumably reflect said someone's\n> authorship.\n\nYou are personifying too much. Git setups where multiple people have\ncommit access are very common, and there's no reason to play them down\njust because Git makes other setups easy.\n\n> If they are interleaved with stuff by others or not doesn't make much\n> (development) sense. Yes, it might be interesting for a software\n> historian, but that's not git's main audience in the first place.\n\nTell that to Junio, our pickaxe guy. :^)\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nThe meaning of Stonehenge in Traflamadorian, when viewed from above, is:\n\"Replacement part being rushed with all possible speed.\"\n"},{"id":"296189","messageId":"4561FDA9.6060807@tromer.org","threadId":"43636","inReplyTo":"200611201709.kAKH9or1012062@laptop13.inf.utfsm.cl","subject":"Re: Feature request: git-pull -e/--edit","fromName":"Eran Tromer","fromEmail":"git2eran@tromer.org","sentAt":"2006-11-20T19:10:33Z","receivedAt":"2006-11-20T19:10:33Z","isPatch":false,"sender":{"key":"git2eran@tromer.org","avatar":null},"body":"On 2006-11-20 19:09, Horst H. von Brand wrote:\n>>\n>> A------------F master\n>> \\ /\n>> B--C--D--E\n>>\n>> Yes, E and F have identical trees. But it's actually *very useful*, if\n>> the commit message at F says \"merged branch foo containing experimental\n>> bar from quux\". And it shows up nicely when looking at gitk.\n> \n> I don't see the usefulness of this. \n\nJust look up this thread for the most recent example: recording the text\nof \"pull foo to get\" and \"[00/05] Fix quux\" message.\n\n\n> And if quux merges back, she gets the same plus a new merge node, and...\n> Linus told everybody (quite forcefully, I might add) that this is not\n> acceptable for distributed development.\n\nI've address this. Sure, it breaks down completely if done by default\nwhen nothing new happens; but not when done judiciously. For real\nproblems to show up you'd need two people who both insist on always\nusing --force-commit when pulling each other. Inevitably, before long\nthey will realize the folly of their ways and stop doing that; problem\nsolved.\n\nI expect common usage to be that --force-commit is only used by\nmaintainers, when pulling/applying non-trivial branches from downstream.\nBut this is a social convention that can be decided per project, and can\nbe ignored by anyone who decides to fork off. And if Linus doesn't like\nit he can just avoid using it in his projects.\n\n\n>> There are the obvious bad consequences if you make this the default,\n>> but how about adding a --force-commit option to merge and pull?\n> \n> Fast forward is fast forward. Merge is when /independent/ changes are\n> integrated into one.\n\nI was under the impression that git-merge is what (indirectly)\ndetermines if joining multiple commits is a fast-forward or a real\nmerge. If it's in some other piece of git, please substitute that.\n\n\n>> You'd need to educate users on how to use this responsibly\n> \n> Looks like you've never met real users ;-)\n\nNo, it's really easy in this case: if someone asks you to pull a rotten\nbranch with too many forced merges, just refuse until he stops abusing\nthat option. It's not the default, right? There are plenty of much worse\nnon-default ways to damage history.\n\n\n>> And to answer Linus: yes, it's expected that only non-leaf developers\n>> will use --force-commit on regular basis, but that's not because\n>> maintainers are technically special in any way. It's just because\n>> maintainers have something useful to say (\"someone's private topic\n>> branch, starting at A and ending at E, has just been accepted into my\n>> all-important public repo and here's why\"). Anyone else can do the same\n>> if he feels likewise.\n> \n> But the individual changes will presumably reflect said someone's\n> authorship. If they are interleaved with stuff by others or not doesn't\n> make much (development) sense. Yes, it might be interesting for a software\n> historian, but that's not git's main audience in the first place.\n\nIf the only thing you care about is the tree of the top commit, then\nsure, those redundant commits are worthless. But then, why do you bother\nwith (for example) commit messages, or tag objects? Oh, you want to know\nmore about what happened and why? Then great, those \"pull foo to get\"\nand \"[00/05]\" messages are probably the best place to start, if we only\nhad where to save them.\n\nWe are all \"software historians\" when we look at some project's public\nbranches and try to grok what's going on recently, who's doing what and\nalong what workflow, and why it got there. This is useful information,\nthat is not easily tracked by any other means; there's a reason this\ncomes up repeatedly in various guises, you know. I can't see why some\npeople are so eager to discard this information and tell others to use a\nmunged-up shortlogs, instead of looking for ways to record as much\npossible with the least negative impact.\n\nNow, --force-commit with appropriate usage conventions seems like a\nreasonable tradeoff.\n\nBTW, in principle another (better?) way to do it is by leaving the\ncommit DAG alone, and annotating it with tag objects where extra\ninformation such as \"[00/05]\" is available. The problem is that git\ndoesn't have any scalable mechanism for adding such annotations. It's a\nhard problem; nothing in the commit DAG points to to tag objects, so you\nhave to scan some external store and that gets more expensive as the\nrepo grows. It also gets nasty in fetches.\n\n Eran\n"},{"id":"296837","messageId":"Pine.LNX.4.63.0611211018040.13772@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"43636","inReplyTo":"4561FDA9.6060807@tromer.org","subject":"Re: Feature request: git-pull -e/--edit","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-11-21T09:19:59Z","receivedAt":"2006-11-21T09:19:59Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 20 Nov 2006, Eran Tromer wrote:\n\n> On 2006-11-20 19:09, Horst H. von Brand wrote:\n> >>\n> >> A------------F master\n> >> \\ /\n> >> B--C--D--E\n> >>\n> >> Yes, E and F have identical trees.\n\nThere has been only _one_ line of history, so why introduce what was not \nthere?\n\nIt sounds more like you do not trust \"E\" to be something especially \nuseful, but in that case you should not merge it to begin with.\n\nCiao,\n"}]}