{"thread":{"id":"993","subject":"Patch (apply) vs. Pull","startedAt":"2005-06-20T16:19:25Z","lastAt":"2005-06-24T13:41:46Z","messageCount":33,"participants":["Darrin Thompson","Junio C Hamano","Daniel Barkalow","Linus Torvalds","Catalin Marinas","Martin Langhoff"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"5084","messageId":"1119284365.3926.15.camel@localhost.localdomain","threadId":"993","inReplyTo":null,"subject":"Patch (apply) vs. Pull","fromName":"Darrin Thompson","fromEmail":"darrint@progeny.com","sentAt":"2005-06-20T16:19:25Z","receivedAt":"2005-06-20T16:19:25Z","isPatch":false,"sender":{"key":"darrint@progeny.com","avatar":null},"body":"In trying to understand git I've adopted a mental model where everybody\nduplicates locally the remote history in which they are interested.\nThese histories have various points in common, allowing for intelligent\nmerging. That makes perfect sense to me, until I look at the list\narchives filled with patches.\n\nHow exactly are these patches being generated? Is there a right-way(tm)\nwhich causes the recipient's a later pullers' histories to be\nintelligently handled in the future?\n\nTIA.\n\n--\nDarrin\n\n\n\n"},{"id":"5086","messageId":"7vbr61j631.fsf@assigned-by-dhcp.cox.net","threadId":"993","inReplyTo":"1119284365.3926.15.camel@localhost.localdomain","subject":"Re: Patch (apply) vs. Pull","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-06-20T17:22:58Z","receivedAt":"2005-06-20T17:22:58Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":">>>>> \"DT\" == Darrin Thompson <darrint@progeny.com> writes:\n\nDT> How exactly are these patches being generated? Is there a right-way(tm)\nDT> which causes the recipient's a later pullers' histories to be\nDT> intelligently handled in the future?\n\nThose patches are, as far as GIT is concerned, out of band\ncommunications.  You could still merge the result if the patch\nwas picked up by more than one tree independently, but the\nbehaviour is a bit less than ideal.  Usually the merge ends up\nto be still manageable.\n\nFYI, here is what I have been doing:\n\n (1) Start from Linus HEAD.\n\n (2) Repeat develop-and-commit cycle.\n\n (3) Run \"git format-patch\" (not in Linus tree) to generate\n     patches.\n\n (4) Send them out and wait to see which one sticks.\n\n (5) Pull from Linus.\n\n (6) Throw away my HEAD, making Linus HEAD my HEAD, while\n     preserving changes I have made since I forked from him.  I\n     use \"jit-rewind\" for this.\n\n (7) Examine patches that Linus rejected, and apply ones that I\n     still consider good, making one commit per patch.  I use\n     \"jit-patch\" and \"jit-commit -m\" for this.\n\n (8) Go back to step 2.\n\n"},{"id":"5096","messageId":"1119308502.3926.18.camel@localhost.localdomain","threadId":"993","inReplyTo":"7vbr61j631.fsf@assigned-by-dhcp.cox.net","subject":"Re: Patch (apply) vs. Pull","fromName":"Darrin Thompson","fromEmail":"darrint@progeny.com","sentAt":"2005-06-20T23:01:42Z","receivedAt":"2005-06-20T23:01:42Z","isPatch":false,"sender":{"key":"darrint@progeny.com","avatar":null},"body":"On Mon, 2005-06-20 at 10:22 -0700, Junio C Hamano wrote:\n>  (6) Throw away my HEAD, making Linus HEAD my HEAD, while\n>      preserving changes I have made since I forked from him.  I\n>      use \"jit-rewind\" for this.\n\nWhen you say it that way it sounds so _bad_. :-)\n\nWould it make sense to come up with a way to make an emailed series of\npatches represent a series of commits? Could patches still be\ncherrypicked?\n\n--\nDarrin\n\n\n"},{"id":"5104","messageId":"Pine.LNX.4.21.0506211337400.30848-100000@iabervon.org","threadId":"993","inReplyTo":"1119308502.3926.18.camel@localhost.localdomain","subject":"Re: Patch (apply) vs. Pull","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-06-21T18:02:05Z","receivedAt":"2005-06-21T18:02:05Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Mon, 20 Jun 2005, Darrin Thompson wrote:\n\n> On Mon, 2005-06-20 at 10:22 -0700, Junio C Hamano wrote:\n> >  (6) Throw away my HEAD, making Linus HEAD my HEAD, while\n> >      preserving changes I have made since I forked from him.  I\n> >      use \"jit-rewind\" for this.\n> \n> When you say it that way it sounds so _bad_. :-)\n\nThe reason is actually that he has to end up with a different history,\nwhich is the history of the project mainline, rather than the history of\nhis tree. He could, of course, follow his own history, but then\ncommunication with people who use a different history becomes difficult.\n\n> Would it make sense to come up with a way to make an emailed series of\n> patches represent a series of commits? Could patches still be\n> cherrypicked?\n\nCommits are fundamentally resistant to cherrypicking, because they give\nthe state of the tree rather than expressing changes in that\nstate. Long-term, I think that something like StGIT should be integrated\ninto the system and deal with generating the HEAD you get after getting\npatches in.\n\n\t-Daniel\n*This .sig left intentionally blank*\n\n"},{"id":"5107","messageId":"Pine.LNX.4.58.0506211452110.2353@ppc970.osdl.org","threadId":"993","inReplyTo":"7vbr61j631.fsf@assigned-by-dhcp.cox.net","subject":"Re: Patch (apply) vs. Pull","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-06-21T22:09:13Z","receivedAt":"2005-06-21T22:09:13Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 20 Jun 2005, Junio C Hamano wrote:\n>\n> FYI, here is what I have been doing:\n> \n>  (1) Start from Linus HEAD.\n> \n>  (2) Repeat develop-and-commit cycle.\n> \n>  (3) Run \"git format-patch\" (not in Linus tree) to generate\n>      patches.\n> \n>  (4) Send them out and wait to see which one sticks.\n> \n>  (5) Pull from Linus.\n> \n>  (6) Throw away my HEAD, making Linus HEAD my HEAD, while\n>      preserving changes I have made since I forked from him.  I\n>      use \"jit-rewind\" for this.\n> \n>  (7) Examine patches that Linus rejected, and apply ones that I\n>      still consider good, making one commit per patch.  I use\n>      \"jit-patch\" and \"jit-commit -m\" for this.\n> \n>  (8) Go back to step 2.\n\nBtw, I'd like to help automate the 6-7 stage with a different kind of \nmerge logic.\n\nThe current \"real merge\" is the global history merge, and that's the kind\nthat I personally want to use, since that's what makes sense from a\n\"project lead\" standpoint and for the people around me in the kernel space\nthat are project leaders of their own.\n\nHowever, as you point out, it's not necessarily the best kind of merge for\nthe \"individual developer\" standpoint. Most individual developers don't\nnecessarily want to merge their work, rather they want to \"bring it\nforward\" to the current tip. And I think git could help with that too.\n\nIt would be somewhat akin to the current git-merge-script, but instead of \nmerging it based on the common parent, it would instead try to re-base all \nthe local commits from the common parent onwards on top of the new remote \nhead. That often makes more sense from the standpoint of a individual \ndeveloper who wants to update his work to the remote head.\n\nSomething like this (this assumes FETCH_HEAD is the remote head that we \njust fetched with \"git fetch xxx\" and that we want to re-base to):\n\n - get the different HEAD info set up, and save the original head in \n   ORIG_HEAD, the way \"git resolve\" does for real merges:\n\n\t: ${GIT_DIR=.git}\n\n\torig=$(git-rev-parse HEAD)\n\tnew=$(git-rev-parse FETCH_HEAD)\n\tcommon=$(git-merge-base $orig $new)\n\n\techo $orig > $GIT_DIR/ORIG_HEAD\n\n - fast-forward to the new HEAD. We'll want to re-base everything off \n   that. If that fails, exit out - we've got dirty state\n\n\tgit-read-tree -m -u $orig $new && exit 1\n\n - for each commit that we had in our old tree but not in the common part, \n   try to re-base it:\n\n\t> FAILED_TO_CHERRYPICK\n\tfor i in $(git-rev-list $orig ^$common)\n\tdo\n\t\tgit-cherry-pick $i ||\n\t\t\t(echo $i >> FAILED_TO_CHERRYPICK)\n\tdone\n\tif [ -s FAILED_TO_CHERRYPICK ]; then\n\t\techo Some commits could not be cherry-picked, check by hand:\n\t\tcat FAILED_TO_CHERRYPICK\n\tfi\n\nand here the \"git-cherry-pick\" thing is just a script that basically takes\nan old commit ID, and tries to re-apply it as a patch (with author data\nand commit messages, of course) on top of the current head. It would \nbasically be nothing more than a \"git-diff-tree $1\" followed by tryign to \nfigure out whether it had already been applied or whether it can be \napplied now.\n\nWhat do you think?\n\n\t\tLinus\n"},{"id":"5113","messageId":"7vd5qeixrd.fsf@assigned-by-dhcp.cox.net","threadId":"993","inReplyTo":"Pine.LNX.4.21.0506211337400.30848-100000@iabervon.org","subject":"Re: Patch (apply) vs. Pull","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-06-22T08:47:18Z","receivedAt":"2005-06-22T08:47:18Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":">>>>> \"DB\" == Daniel Barkalow <barkalow@iabervon.org> writes:\n\nDB> On Mon, 20 Jun 2005, Darrin Thompson wrote:\n>> On Mon, 2005-06-20 at 10:22 -0700, Junio C Hamano wrote:\n>> >  (6) Throw away my HEAD, making Linus HEAD my HEAD, while\n>> >      preserving changes I have made since I forked from him.  I\n>> >      use \"jit-rewind\" for this.\n>> \n>> When you say it that way it sounds so _bad_. :-)\n\nDB> The reason is actually that he has to end up with a different history,\n\nExactly.  I _want_ to, not just _have_ to, end up with a\ndifferent history.\n\n"},{"id":"5116","messageId":"7vmzpihi6x.fsf@assigned-by-dhcp.cox.net","threadId":"993","inReplyTo":"Pine.LNX.4.58.0506211452110.2353@ppc970.osdl.org","subject":"Re: Patch (apply) vs. Pull","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-06-22T09:08:54Z","receivedAt":"2005-06-22T09:08:54Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":">>>>> \"LT\" == Linus Torvalds <torvalds@osdl.org> writes:\n\nLT> and here the \"git-cherry-pick\" thing is just a script that basically takes\nLT> an old commit ID, and tries to re-apply it as a patch (with author data\nLT> and commit messages, of course) on top of the current head. It would \nLT> basically be nothing more than a \"git-diff-tree $1\" followed by tryign to \nLT> figure out whether it had already been applied or whether it can be \nLT> applied now.\n\nLT> What do you think?\n\nWhat you outlined is essentially what I already do by using\njit-rewind, followed by a repeated use of (jit-patch and\njit-commit with -m flag).  The reason I have not automated the\n\"repeat\" part is _not_ because I am lazy, but because typically\nthe rejected things really need manual intervention, not for\nmechanical (read: merge conflict) reasons, but for semantic\nreasons, when some patches are accepted while some others are\nnot.  Especially if I am not the sole supplier of patches to\nyour tree, my older patches usually need not just rebasing but\n_rethinking_, so I myself do not find need for automating things\nfurther that much from what I already have.\n\nHaving said that, one automation I would benefit from is to\nautomatically find patches that _have_ been accepted and drop\nthem from my snapshot pool --- that part should be very easy to\nautomate and I have not done so primarily because I _am_ lazy.\nI could call it git-cherry-drop ;-).\n\n\n"},{"id":"5117","messageId":"tnxvf46btpt.fsf@arm.com","threadId":"993","inReplyTo":"Pine.LNX.4.21.0506211337400.30848-100000@iabervon.org","subject":"Re: Patch (apply) vs. Pull","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2005-06-22T09:56:30Z","receivedAt":"2005-06-22T09:56:30Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"Daniel Barkalow <barkalow@iabervon.org> wrote:\n> On Mon, 20 Jun 2005, Darrin Thompson wrote:\n>> Would it make sense to come up with a way to make an emailed series of\n>> patches represent a series of commits? Could patches still be\n>> cherrypicked?\n\nWhile you could cherry-pick a changeset generated by a commit\n(i.e. the diff between the commit's tree and its parent), I found this\nnot to always be convenient. For example, a fix might need more than\none commit but there is no way to know how they relate and which\nchangesets to cherry-pick, unless somebody tells you exactly.\n\n> Commits are fundamentally resistant to cherrypicking, because they give\n> the state of the tree rather than expressing changes in that\n> state. Long-term, I think that something like StGIT should be integrated\n> into the system and deal with generating the HEAD you get after getting\n> patches in.\n\nWith StGIT, you can gather many related commits into a patch. This\npatch (i.e. a series of related commits) could be pulled into your\ntree and pushed onto your stack of patches. StGIT should also allow\none to upgrade the pulled patch and re-applied onto the stack.\n\nThanks to Daniel's suggestion for multiple heads support, StGIT will\n(in a future release) support pulling changes from a remote tree\ntogether with the patch series information. After this is done,\napplying patches from different branch (head) would be quite simple.\n\nOne problem is patch dependency tracking (i.e. you cannot push a patch\nonto the stack if it expects a certain patch to be already\napplied). Darcs does this by checking whether two patches can be\ncommuted. I have to think a bit more about how StGIT could handle\nthis.\n\n-- \nCatalin\n\n"},{"id":"5118","messageId":"1119457403.4128.18.camel@localhost.localdomain","threadId":"993","inReplyTo":"Pine.LNX.4.58.0506211452110.2353@ppc970.osdl.org","subject":"Re: Patch (apply) vs. Pull","fromName":"Darrin Thompson","fromEmail":"darrint@progeny.com","sentAt":"2005-06-22T16:23:23Z","receivedAt":"2005-06-22T16:23:23Z","isPatch":false,"sender":{"key":"darrint@progeny.com","avatar":null},"body":"On Tue, 2005-06-21 at 15:09 -0700, Linus Torvalds wrote:\n> However, as you point out, it's not necessarily the best kind of merge for\n> the \"individual developer\" standpoint. Most individual developers don't\n> necessarily want to merge their work, rather they want to \"bring it\n> forward\" to the current tip. And I think git could help with that too.\n> \n\nThat's a good way to put it.\n\n> and here the \"git-cherry-pick\" thing is just a script that basically takes\n> an old commit ID, and tries to re-apply it as a patch (with author data\n> and commit messages, of course) on top of the current head. It would \n> basically be nothing more than a \"git-diff-tree $1\" followed by tryign to \n> figure out whether it had already been applied or whether it can be \n> applied now.\n> \n> What do you think?\n\nHere are two desirable things the might be tough to reconcile:\n\n- The merging mechanism might benefit from knowing that your commit was\nreally originally my commit _if_ my history is relevant to the merge and\npresent.\n\n- The rest of the world does _not_ want to have to keep my commits on\nhand just to follow the mainline.\n\nI imagine if those could be reconciled you'd hit a sweet spot.\n\nA mechanism where those two were true might also provide better hooks\nfor knowing other things. For instance, which of these particular\ncommits of mine are not in the mainline tree? \n\nPerhaps your mainline commit might refer to my humble commit as some\nkind of sibling. You don't need to have it to follow the mainline, but\nthe data is there if it helps anybody.\n\n--\nDarrin\n\n\n"},{"id":"5119","messageId":"tnx1x6u9vbk.fsf@arm.com","threadId":"993","inReplyTo":"7vbr61j631.fsf@assigned-by-dhcp.cox.net","subject":"Re: Patch (apply) vs. Pull","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2005-06-22T17:04:47Z","receivedAt":"2005-06-22T17:04:47Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"Have a look at StGIT for this, it might help.\n\nJunio C Hamano <junkio@cox.net> wrote:\n> FYI, here is what I have been doing:\n>\n>  (1) Start from Linus HEAD.\n>\n>  (2) Repeat develop-and-commit cycle.\n\nGather the related commits into an StGIT patch. It's actually easier\nto only update a set of existing patches, similar to the quilt way.\n\nstg new patch1\nmodify...\nstg commit\nmodify...\nstg commit\n\nstg push/pop/new\n\netc.\n\n>  (3) Run \"git format-patch\" (not in Linus tree) to generate\n>      patches.\n\nstg export. The problem with this one is that it doesn't preserve any\nof the commit information but it can be adapted (though I'm not sure\nit is worth since the patch won't be that readable).\n\n>  (4) Send them out and wait to see which one sticks.\n>\n>  (5) Pull from Linus.\n>\n>  (6) Throw away my HEAD, making Linus HEAD my HEAD, while\n>      preserving changes I have made since I forked from him.  I\n>      use \"jit-rewind\" for this.\n\nstg pop -a. This will remove all your changes grouped in stgit\npatches. The HEAD is now Linus' old HEAD. Pull/merge will advance the\nHEAD to Linus' latest HEAD.\n\n>  (7) Examine patches that Linus rejected, and apply ones that I\n>      still consider good, making one commit per patch.  I use\n>      \"jit-patch\" and \"jit-commit -m\" for this.\n\nstg push -a. This step will do a diff3 between the current HEAD and\nthe top of the patch as the two branches, and the bottom of the patch\nas an ancestor.\n\nIf the patch was merged unmodified, stgit detects this and warns you\nthat the patch is now empty (it detects it even if a file contains\nother modifications apart from yours). If you modified it in the\nmeantime or the Linus modified it when merged (or some other third\nparty patch modifies yours), you will get a conflict you can resolve.\n\n>  (8) Go back to step 2.\n\n-- \nCatalin\n\n"},{"id":"5120","messageId":"Pine.LNX.4.58.0506221009120.2353@ppc970.osdl.org","threadId":"993","inReplyTo":"7vmzpihi6x.fsf@assigned-by-dhcp.cox.net","subject":"Re: Patch (apply) vs. Pull","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-06-22T17:21:00Z","receivedAt":"2005-06-22T17:21:00Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 22 Jun 2005, Junio C Hamano wrote:\n> \n> Having said that, one automation I would benefit from is to\n> automatically find patches that _have_ been accepted and drop\n> them from my snapshot pool --- that part should be very easy to\n> automate and I have not done so primarily because I _am_ lazy.\n> I could call it git-cherry-drop ;-).\n\nAndrew Morton does all of this with quilt, and it ends up being very\neffective. Of course, the kernel has had almost 15 years of people making \nit more and more modular, so the kernel really gets rejects very seldom \nindeed, and it would probably not work as well for other projects \n(including git) that tend to have tighter couplings, if for no other \nreason than the fact that they are usually smaller.\n\nAnyway, it's not a trivial problem. You can search for patch matches in\nthe patch history, but the thing is, that will fail whenever a patch was\nedited for whitespace etc (which does end up happening often enough to\nmatter). The same goes even more for the commit messages (I routinely not\nonly add my sign-off, of course, but also fix typo's I notice and often\nend up reformatting whitespace).\n\nSo at the very least, you'd have to have a fuzzy search (but exact enough \nthat you'd see if a part of a patch was dropped etc).\n\n\t\t\tLinus\n"},{"id":"5122","messageId":"Pine.LNX.4.21.0506221350130.30848-100000@iabervon.org","threadId":"993","inReplyTo":"Pine.LNX.4.58.0506221009120.2353@ppc970.osdl.org","subject":"Re: Patch (apply) vs. Pull","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-06-22T20:08:16Z","receivedAt":"2005-06-22T20:08:16Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Wed, 22 Jun 2005, Linus Torvalds wrote:\n\n> Anyway, it's not a trivial problem. You can search for patch matches in\n> the patch history, but the thing is, that will fail whenever a patch was\n> edited for whitespace etc (which does end up happening often enough to\n> matter). The same goes even more for the commit messages (I routinely not\n> only add my sign-off, of course, but also fix typo's I notice and often\n> end up reformatting whitespace).\n\nIf each patch is given an ID by the author (not committer) which is\npreserved across various later modifications, we could at least recognize\nwhich patch it was. Then we could present the author with the information\nthat the patch was accepted and was modified, and give the author the\noption of replacing it in the series with one that reverts some or all of\nthe modifications (including re-adding dropped portions). I don't see any\nreason that it would be better to search for similarity rather than just\nhaving things explicitly tagged (I think, although I'm not sure, that\nauthors will care about the difference between someone applying an\nalternative patch and someone applying the author's patch with\nmodifications.\n\n\t-Daniel\n*This .sig left intentionally blank*\n\n"},{"id":"5123","messageId":"Pine.LNX.4.58.0506221315201.2353@ppc970.osdl.org","threadId":"993","inReplyTo":"Pine.LNX.4.21.0506221350130.30848-100000@iabervon.org","subject":"Re: Patch (apply) vs. Pull","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-06-22T20:22:46Z","receivedAt":"2005-06-22T20:22:46Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 22 Jun 2005, Daniel Barkalow wrote:\n>\n> If each patch is given an ID by the author (not committer) which is\n> preserved across various later modifications, we could at least recognize\n> which patch it was.\n\nI really don't like it.\n\nI do realize that people use patch ID's inside various companies already, \nbecause it's a nice way to track things. But the fact is, especially with \nthe patch going outside the SCM (which is the whole _point_ here, after \nall), any modifications will make that ID be dubious.\n\nAnd if it _isn't_ modified, then the ID is pointless - you might as well \nuse the SHA1 of the patch itself as its ID, ie not use an explicit ID at \nall.\n\nSo I think introducing extra ID's in the process only creates the\npossibility for more confusion. Either the patch is unmodified (and the ID\nis not needed in the first place) or the patch is modified (and the ID\ndoesn't convey that). Not to mention the fact that the ID then becomes \njust another thing that can get corrupted or lost or just plain mistakenly \nedited from another patch..\n\nSo while I do accept ID's in my workflow (the XFS guys use them to track\ncommits between their own internal system and the kernel releases), I\nreally don't like it as a primary mechanism. I think it's useful for\nspecific projects, but any such usefulness is exactly the fact that then\nthe tracking of the ID's is totally outside of git itself or any of the\nprocesses of git users.\n\nWhich of course is ok, but it's _not_ what I'm interested in if we're\ndiscussing trying to make git itself have some support for \"end-developer\nmerges\" (re-write history) as opposed to \"maintainer merges\" (merge\nhistory).\n\n\t\tLinus\n"},{"id":"5125","messageId":"Pine.LNX.4.21.0506221654550.30848-100000@iabervon.org","threadId":"993","inReplyTo":"Pine.LNX.4.58.0506221315201.2353@ppc970.osdl.org","subject":"Re: Patch (apply) vs. Pull","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-06-22T21:54:01Z","receivedAt":"2005-06-22T21:54:01Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Wed, 22 Jun 2005, Linus Torvalds wrote:\n\n> I do realize that people use patch ID's inside various companies already, \n> because it's a nice way to track things. But the fact is, especially with \n> the patch going outside the SCM (which is the whole _point_ here, after \n> all), any modifications will make that ID be dubious.\n\nIf this were done within the system, the maintainer would merge a commit\nfrom the author, commit, fix up the whitespace, commit, and push out the\nresult. The developer then sees that the head was merged, and that\nwhitespace changes were applied on top of that.\n\nThe benefit to an ID that doesn't get changed is that the developer (or\nthe developer's scripts) can tell that the patch is an ancestor of the new\nbase tree, which is really important information about maintainer\nintent: the remnant in this case is a revert of the maintainer's\nchanges to the patch, not an independant but conflicting patch.\n\n> And if it _isn't_ modified, then the ID is pointless - you might as well \n> use the SHA1 of the patch itself as its ID, ie not use an explicit ID at \n> all.\n\nMy thought was actually to use the hash as the ID, and add headers for\n\"this patch is a descendant of <other-ID>\" as it gets tweaked.\n\nBut even in the case where the patch is not modified, the developer can't\nretrieve the hash of the applied patch, because it may have applied with\nfuzz, in which case diffing the parent's tree with the tree wouldn't\ngenerate a byte-for-byte identical patch. So it would be worth having the\ncommit store the hash of the submitted patch in a header anyway.\n\n> So I think introducing extra ID's in the process only creates the\n> possibility for more confusion. Either the patch is unmodified (and the ID\n> is not needed in the first place) or the patch is modified (and the ID\n> doesn't convey that).\n\nDo you actually modify patches before applying them, rather than applying\nthem and the fixing the resulting files? I've never managed to modify\ncontent in a patch (aside from dropping hunks) without upsetting patch. If\nyou apply them and then fix things, the ID (and for that matter, the \nhash) will be safely conveyed from my system to yours and available for\nthe commit to mention.\n\n> Which of course is ok, but it's _not_ what I'm interested in if we're\n> discussing trying to make git itself have some support for \"end-developer\n> merges\" (re-write history) as opposed to \"maintainer merges\" (merge\n> history).\n\nI believe there are separate issues here: \n\n 1. pure history rewriting: maintainer merges a developer's\n    intermediate head; developer generates a new history in which\n    everything later is based on the new mainline.\n 2. patches: changes are transferred as diffs over SMTP instead of trees\n    inside git.\n 3. cherry-picking: maintainer applies some set of changes from a\n    developer which is not merging a head the developer created.\n\nI think (1) is easily handled as a merge script that goes through a series\nof commits and makes a new series out of merging each of them, rather than\nmerging the last of them only.\n\nI think (2) should be as transparent as possible, and, in cases where\nthere was no cherry-picking, be equivalent in the system's behavior to the\nresult of pull and merge (with the possibility for various cleanup \nhappening on top of or along with the merge in either method).\n\nThe tricky part is (3), which is currently only possible by going outside\nof git. But I think that this is something to tackle separately from\n(1) and (2) (where (2) does not involve doing (3)).\n\n\t-Daniel\n*This .sig left intentionally blank*\n\n"},{"id":"5126","messageId":"Pine.LNX.4.58.0506221504370.2353@ppc970.osdl.org","threadId":"993","inReplyTo":"Pine.LNX.4.21.0506221654550.30848-100000@iabervon.org","subject":"Re: Patch (apply) vs. Pull","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-06-22T22:21:14Z","receivedAt":"2005-06-22T22:21:14Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 22 Jun 2005, Daniel Barkalow wrote:\n> \n> Do you actually modify patches before applying them, rather than applying\n> them and the fixing the resulting files? I've never managed to modify\n> content in a patch (aside from dropping hunks) without upsetting patch.\n\nI've been doing unified diffs for a _loong_ time, and I edit patches in my \nsleep. The rules for line numbers etc are really quite simple, and yes, I \ndo edit patches before I apply them.\n\nThe most common form of editing is just removing single fragments, or\nfixing up whitespace. Quite often people send me patches that don't even\napply, because whitespace got corrupted either because their mailer ate\nit, or simply because they cut-and-pasted the patch. So I end up fixing\nthings up, and the end result may not actually match the original one\nbyte-for-byte, even if it matches visually.\n\nSimilarly, the \"remove patch fragments\" is often because somebody mixes up\ntwo things in a patch, and I decide to take one of them but there's some\nproblem with the other.  Sometimes that patch fragment thing means that I\nhave to edit even within one fragment, and fix up the patch line-counters\netc.\n\nNOTE! This is \"rare\" in the sense that it doesn't happen for most patches,\nbut that said, I get a _lot_ of patches, and it's not rare in the sense\nthat it doesn't happen weekly.\n\nSo for example, I did one such edit just Monday in the \"sparse\" project,\nwhere Peter Jones sent me a patch that added parsing for a lot of new gcc\nattributes (good), but he had also done some other things that weren't\nquite ready yet (bad). And because they were easy to separate out in the\npatch, I just did it right there instead of asking him to do it for me and\nre-sending.\n\n> If you apply them and then fix things, the ID (and for that matter, the\n> hash) will be safely conveyed from my system to yours and available for\n> the commit to mention.\n\nI don't want crap in my code. I disagree very strongly with people who say\nthat \"you can just fix it later\". That's not how people work, and worst of\nall, not only does it not get fixed up, even _if_ it is fixed up the wrong\nversion inevitably ends up showing up somewhere else, just because\nsomebody ended up using the original patch.\n\nSo I want things to be cleaned up before they hit the tree, rather than \nhave a really dirty history. A dirty history just makes it harder to read, \nand I don't believe in a second that it's \"closer to reality\" like some \npeople claim.\n\nI don't believe anybody wants to see the \"true\" history. If they did, we'd \nbe logging keystrokes, and sending all of that around. Nope, people want \n(and need, in order to be able to follow it) an \"idealized\" history.\n\n> I believe there are separate issues here: \n> \n>  1. pure history rewriting: maintainer merges a developer's\n>     intermediate head; developer generates a new history in which\n>     everything later is based on the new mainline.\n>  2. patches: changes are transferred as diffs over SMTP instead of trees\n>     inside git.\n>  3. cherry-picking: maintainer applies some set of changes from a\n>     developer which is not merging a head the developer created.\n> \n> I think (1) is easily handled as a merge script that goes through a series\n> of commits and makes a new series out of merging each of them, rather than\n> merging the last of them only.\n\nYes. And I think (1) is pretty useful on its own, and that git could \nsupport that with a nice helper script.\n\n> I think (2) should be as transparent as possible, and, in cases where\n> there was no cherry-picking, be equivalent in the system's behavior to the\n> result of pull and merge (with the possibility for various cleanup \n> happening on top of or along with the merge in either method).\n\nI really see patches as something totally different than merging. I \nliterally see them as a way to move between different systems.\n\nFor example, the git model just doesn't work very well for \"fluid\" \ndevelopment: git ends up setting history entirely in stone, which means \nthat you can't fix up mistakes later. And this is where patches come in: \nthey work as a way to transfer the information, while at the same time \ntotally breaking the connection with the original messy tree.\n\nSo I really think our view on what \"patches\" are is very fundamentally \ndifferent. I don't think SMTP is a good medium for merges: BK actually \nsupports that with \"bk send\" (or something like that) and I refused to use \nit. It was a \"worst of both worlds\" thing.\n\n> The tricky part is (3), which is currently only possible by going outside\n> of git. But I think that this is something to tackle separately from\n> (1) and (2) (where (2) does not involve doing (3)).\n\nI think the cherry-picking kind of goes hand in hand with 1/2, though. \nPatches are really the perfect form of cherry-picking, exactly because \nthey do _not_ imply a very strong ordering or even a very strong \ndependency on the state of the rest of the sources. So patches end up \nbeing the perfect medium for cherry-picking, and SMTP ends up being one of \nthe best ways to transport them and let them evolve.\n\nAnd then (1) ends up often being the way the patches actually get \ngenerated in the first place. So these things are intertwined, I think.\n\n\t\tLinus\n"},{"id":"5155","messageId":"Pine.LNX.4.21.0506221821260.30848-100000@iabervon.org","threadId":"993","inReplyTo":"Pine.LNX.4.58.0506221504370.2353@ppc970.osdl.org","subject":"Re: Patch (apply) vs. Pull","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-06-23T03:32:15Z","receivedAt":"2005-06-23T03:32:15Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Wed, 22 Jun 2005, Linus Torvalds wrote:\n\n> I've been doing unified diffs for a _loong_ time, and I edit patches in my \n> sleep. The rules for line numbers etc are really quite simple, and yes, I \n> do edit patches before I apply them.\n\nAh, okay. I actually know the rules for line numbers, and I still can't\nchange the lines and line numbers reliably in sync.\n\n> Similarly, the \"remove patch fragments\" is often because somebody mixes up\n> two things in a patch, and I decide to take one of them but there's some\n> problem with the other.  Sometimes that patch fragment thing means that I\n> have to edit even within one fragment, and fix up the patch line-counters\n> etc.\n\nRight; I do this myself, when I turn a mass of changes into a set of\npatches. I think it would be worth having a good tool for applying a\npatch while discarding undesired hunks and editing the regions it applies\nto. This is, of course, not immediately relevant, aside from it making the\ntracking more useful, because more people would be able to reliably modify\npatches. In any case, though, after you've fixed a patch, you apply it\nrather than sending it to anyone or archiving it or something, right?\n\n> NOTE! This is \"rare\" in the sense that it doesn't happen for most patches,\n> but that said, I get a _lot_ of patches, and it's not rare in the sense\n> that it doesn't happen weekly.\n\nI think it would we worthwhile for the common case for the system to\nrecognize that a patch went in unmodified, but potentially after a\ndifferent patch which caused it to have fuzz, and have a header that would\nget the developer's update to recognize what happened.\n\n> I don't want crap in my code. I disagree very strongly with people who say\n> that \"you can just fix it later\". That's not how people work, and worst of\n> all, not only does it not get fixed up, even _if_ it is fixed up the wrong\n> version inevitably ends up showing up somewhere else, just because\n> somebody ended up using the original patch.\n\nIf you can modify patches, that's better; I think most maintainers would\nfall back to applying the patch and fixing things in the working directory\nbefore committing; the history still doesn't get dirty, which is what\nactually matters.\n\n> > I believe there are separate issues here: \n> > \n> >  1. pure history rewriting: maintainer merges a developer's\n> >     intermediate head; developer generates a new history in which\n> >     everything later is based on the new mainline.\n> >  2. patches: changes are transferred as diffs over SMTP instead of trees\n> >     inside git.\n> >  3. cherry-picking: maintainer applies some set of changes from a\n> >     developer which is not merging a head the developer created.\n> > \n> > I think (1) is easily handled as a merge script that goes through a series\n> > of commits and makes a new series out of merging each of them, rather than\n> > merging the last of them only.\n> \n> Yes. And I think (1) is pretty useful on its own, and that git could \n> support that with a nice helper script.\n\nI think that this, by itself, is likely to be a sufficiently common case\nto be worth just doing. Once the script exists, it makes it worthwhile for\ndevelopers to organize things such that it works.\n\nE.g., yesterday, I'd have had:\n\nYou -- A1 -- A2\n \\             \\\n  ----- B ------ Stuff I've sent -- Stuff I'm working on\n\nIf you pulled A1 or A2, and/or B, the script would take care of everything\nwithout any fuss. I didn't actually make this structure of commits,\nhowever, because I didn't have the script that would make it useful. \n\n> > I think (2) should be as transparent as possible, and, in cases where\n> > there was no cherry-picking, be equivalent in the system's behavior to the\n> > result of pull and merge (with the possibility for various cleanup \n> > happening on top of or along with the merge in either method).\n> \n> I really see patches as something totally different than merging. I \n> literally see them as a way to move between different systems.\n> \n> For example, the git model just doesn't work very well for \"fluid\" \n> development: git ends up setting history entirely in stone, which means \n> that you can't fix up mistakes later. And this is where patches come in: \n> they work as a way to transfer the information, while at the same time \n> totally breaking the connection with the original messy tree.\n\nI certainly use patches internally as a way of going from my messy\ndevelopment tree to my clean patch tree. But that's mostly a developer's\nown usage. (I suppose developers might diff their latest commit against\nthe mainline, and then hand-edit it into a series without regenerating\npatches, but I think that would be really awkward and failure-prone for\nnon-experts in unified diff.)\n\nBut I think that the real value of patches for submission as opposed to\nmerges is that you can review them conveniently. It's not just that\nthey're machine-readable and can apply with fuzz; they're also pretty easy\nfor humans to read, which is why unified diffs are better than context\ndiffs, despite having the same expressive power. In this case, then, they\naren't being used for cherry-picking or any other history cleaning; you'll\ntend to apply the patch straight (or reject it), and then it would be\nuseful to have it act like a merge, with respect to further operations\nunderstanding what happened.\n\n> So I really think our view on what \"patches\" are is very fundamentally \n> different. I don't think SMTP is a good medium for merges: BK actually \n> supports that with \"bk send\" (or something like that) and I refused to use \n> it. It was a \"worst of both worlds\" thing.\n\nCertainly, if you trust the result enough to merge, there's no need to\nreview anything and therefore no need to go through email.\n\n> > The tricky part is (3), which is currently only possible by going outside\n> > of git. But I think that this is something to tackle separately from\n> > (1) and (2) (where (2) does not involve doing (3)).\n> \n> I think the cherry-picking kind of goes hand in hand with 1/2, though. \n> Patches are really the perfect form of cherry-picking, exactly because \n> they do _not_ imply a very strong ordering or even a very strong \n> dependency on the state of the rest of the sources. So patches end up \n> being the perfect medium for cherry-picking, and SMTP ends up being one of \n> the best ways to transport them and let them evolve.\n\nI think that cherry-picking depends on 1/2, but that each of them has a\nnon-cherry-picking case worth supporting specifically.\n\n\t-Daniel\n*This .sig left intentionally blank*\n\n"},{"id":"5156","messageId":"Pine.LNX.4.58.0506222059150.11175@ppc970.osdl.org","threadId":"993","inReplyTo":"Pine.LNX.4.21.0506221821260.30848-100000@iabervon.org","subject":"Re: Patch (apply) vs. Pull","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-06-23T04:23:31Z","receivedAt":"2005-06-23T04:23:31Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 22 Jun 2005, Daniel Barkalow wrote:\n> \n> Ah, okay. I actually know the rules for line numbers, and I still can't\n> change the lines and line numbers reliably in sync.\n\nHeh. I usually just edit the fragment, and ignore the line numbers, and \nthen I go back and just count ;)\n\nSo I don't even try to keep things in sync, I just fix them up \nafter-the-fact.\n\n> Right; I do this myself, when I turn a mass of changes into a set of\n> patches. I think it would be worth having a good tool for applying a\n> patch while discarding undesired hunks and editing the regions it applies\n> to.\n\nThere at least one GNU emacs \"patch mode\" editing thing to help you, and I\nthink there is even a tool specifically geared to splitting up a patch\ninto several sub-patches. I've been pointed at it occasionally, I just do \nit by hand.\n\n> I think it would we worthwhile for the common case for the system to\n> recognize that a patch went in unmodified, but potentially after a\n> different patch which caused it to have fuzz, and have a header that would\n> get the developer's update to recognize what happened.\n\nNote that I don't even apply patches with fuzz at all. \"git-apply\" refuses \nto recognize anything with fuzz, although it _will_ move the patch around \nto make it match.\n\nI've got this theory that if you apply a thousand patches, and one of them \napplies with fuzz, you want to stop right there and see what's wrong.\n\nThis was what I did before I wrote \"git-apply\":\n\n\tpatch -E -u --no-backup-if-mismatch -f -p1 --fuzz=0 --input=$PATCHFILE\n\nie pretty unambiguous. I don't trust the \"automatically guess the depth of \nthe patch\" thing, for example, since it, together with allowing fuzz, has \nseveral times caused nasty problems for me with things like the wrong \nMakefile being modified by a patch..\n\nSo as far as I'm concerned, you really could just take the SHA1 of the\npatch (leave out the '@@' lines with line numbers), and you'd have a\nreliable ID for it.\n\nIn fact, you could probably replace every run of contiguous whitespace\nwith a single space, and then you'd not have to worry about whitespace\ndifferences either. That would be very simple to do, and quite workable: I\ncertainly think it sounds more reliable than just hoping that people\nalways pass on a \"patch ID\" in their emails..\n\n> > I don't want crap in my code. I disagree very strongly with people who say\n> > that \"you can just fix it later\". That's not how people work, and worst of\n> > all, not only does it not get fixed up, even _if_ it is fixed up the wrong\n> > version inevitably ends up showing up somewhere else, just because\n> > somebody ended up using the original patch.\n> \n> If you can modify patches, that's better; I think most maintainers would\n> fall back to applying the patch and fixing things in the working directory\n> before committing; the history still doesn't get dirty, which is what\n> actually matters.\n\nThe reason I much prefer editing patches is my batch-mode approach to then\napplying them. If I were to fix things up after applying a patch, I'd have\nto break up the series: apply <n> patches, fix up, apply <m> patches, fix\nup, etc. In contrast, now I just fix up the mbox directly (at a minimum,\nadd the sign-off, even if I don't actually touch the patch itself), and\njust apply it all in one go.\n\nBut yes, if it's a nasty case, I'll just apply it, edit it, re-create a\ndiff, and then re-apply it with the re-created diff (since all my tools\nare geared towards getting the log message etc with the patch, I don't\njust commit it after fixing it up: that would screw up the author\ninformation etc).\n\n> > Yes. And I think (1) is pretty useful on its own, and that git could \n> > support that with a nice helper script.\n> \n> I think that this, by itself, is likely to be a sufficiently common case\n> to be worth just doing. Once the script exists, it makes it worthwhile for\n> developers to organize things such that it works.\n\nYeah. It probably works well in 99% of the cases to just do a simple\n\"export as patch\" + \"apply on top with old commit message, author and\nauthor-date\".\n\n> But I think that the real value of patches for submission as opposed to\n> merges is that you can review them conveniently.\n\nYes, agreed (with the exception of how I tend to merge with Andrew, where \nit's really more of a regular merge in the sense of \"I pull from Andrew \nbecause I trust him, not because I look at every patch\").\n\n> It's not just that\n> they're machine-readable and can apply with fuzz; they're also pretty\n> easy for humans to read, which is why unified diffs are better than\n> context diffs, despite having the same expressive power. In this case,\n> then, they aren't being used for cherry-picking or any other history\n> cleaning; you'll tend to apply the patch straight (or reject it), and\n> then it would be useful to have it act like a merge, with respect to\n> further operations understanding what happened.\n\nI've _occasionally_ wanted patches to work that way, just because they \ndon't apply, but they'd apply to the right version and then I could just \nmerge them. So yes, sometimes a patch might be more of a merge thing. Most \nof the time, the patch has really been around the block several times, and \nit's really lost it's position in the history tree.. So it really ends up \nbeing \"just apply it to the top\" 99% of the time anyway.\n\n\t\tLinus\n"},{"id":"5161","messageId":"Pine.LNX.4.21.0506230025420.30848-100000@iabervon.org","threadId":"993","inReplyTo":"Pine.LNX.4.58.0506222059150.11175@ppc970.osdl.org","subject":"Re: Patch (apply) vs. Pull","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-06-23T05:15:52Z","receivedAt":"2005-06-23T05:15:52Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Wed, 22 Jun 2005, Linus Torvalds wrote:\n\n> On Wed, 22 Jun 2005, Daniel Barkalow wrote:\n> > I think it would we worthwhile for the common case for the system to\n> > recognize that a patch went in unmodified, but potentially after a\n> > different patch which caused it to have fuzz, and have a header that would\n> > get the developer's update to recognize what happened.\n> \n> Note that I don't even apply patches with fuzz at all. \"git-apply\" refuses \n> to recognize anything with fuzz, although it _will_ move the patch around \n> to make it match.\n\nI bet I'm misunderstanding fuzz; what I actually mean is that, if a patch\napplies after moving it, then regenerating it from the result would give\nthe a patch with different line numbers; if these affect the hash, the\nauthor's tools will be sad.\n\n> So as far as I'm concerned, you really could just take the SHA1 of the\n> patch (leave out the '@@' lines with line numbers), and you'd have a\n> reliable ID for it.\n>\n> In fact, you could probably replace every run of contiguous whitespace\n> with a single space, and then you'd not have to worry about whitespace\n> differences either. That would be very simple to do, and quite workable: I\n> certainly think it sounds more reliable than just hoping that people\n> always pass on a \"patch ID\" in their emails..\n\nThat's actually quite plausible. The only case it wouldn't handle is when\nyou actually discard parts, and I'm not sure at this point what other\npeople should see there.\n\n> But yes, if it's a nasty case, I'll just apply it, edit it, re-create a\n> diff, and then re-apply it with the re-created diff (since all my tools\n> are geared towards getting the log message etc with the patch, I don't\n> just commit it after fixing it up: that would screw up the author\n> information etc).\n\nI think most people's scripts stash the information needed for the commit\nsomewhere, and pick it back up at commit time, at least for merges.\n\n> > > Yes. And I think (1) is pretty useful on its own, and that git could \n> > > support that with a nice helper script.\n> > \n> > I think that this, by itself, is likely to be a sufficiently common case\n> > to be worth just doing. Once the script exists, it makes it worthwhile for\n> > developers to organize things such that it works.\n> \n> Yeah. It probably works well in 99% of the cases to just do a simple\n> \"export as patch\" + \"apply on top with old commit message, author and\n> author-date\".\n\nI think that you'll get better results out of \"merge with top\" + \"commit\nwith old commit info, but not listing old commit as a parent\". At least,\nthat's what StGIT is doing, IIRC, and using merge instead of patch seems\nlike it'll make the remaining 1% a lot more pleasant. In fact, isn't it\nnecessary if you want to make sense out of \"half of my patch got applied\",\nas a bunch of \"still needed\" hunks and a bunch of \"already applied\" hunks \nthat disappear after the message?\n\n> > It's not just that\n> > they're machine-readable and can apply with fuzz; they're also pretty\n> > easy for humans to read, which is why unified diffs are better than\n> > context diffs, despite having the same expressive power. In this case,\n> > then, they aren't being used for cherry-picking or any other history\n> > cleaning; you'll tend to apply the patch straight (or reject it), and\n> > then it would be useful to have it act like a merge, with respect to\n> > further operations understanding what happened.\n> \n> I've _occasionally_ wanted patches to work that way, just because they \n> don't apply, but they'd apply to the right version and then I could just \n> merge them. So yes, sometimes a patch might be more of a merge thing. Most \n> of the time, the patch has really been around the block several times, and \n> it's really lost it's position in the history tree.. So it really ends up \n> being \"just apply it to the top\" 99% of the time anyway.\n\nIt should be fine as a merge if you apply it to the top; the case that's\ncherry-picking is when you apply a patch that was second in a series\nwithout applying the first. By \"like a merge\" I really mean \"someone\nchanged <old> to <patched>; I want to make that change to <new>, such that\nfuture merges aren't confused.\" In this case, you'd actually generate only\nan \"apply\" commit, not recreate (or fetch) \"patched-old\" and generate a\nmerge commit. But, if you put the hash of the patch (as above) in a commit\nheader, other people who have the same patch (including the author) can\nidentify the commonality and not be confused. (I think putting\nit in a header is likely necessary for efficiency reasons, so that it\nisn't necessary to unpack/diff/hash all of the trees while updating.)\n\n\t-Daniel\n*This .sig left intentionally blank*\n\n"},{"id":"5165","messageId":"Pine.LNX.4.58.0506222258290.11175@ppc970.osdl.org","threadId":"993","inReplyTo":"Pine.LNX.4.21.0506230025420.30848-100000@iabervon.org","subject":"Re: Patch (apply) vs. Pull","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-06-23T06:09:48Z","receivedAt":"2005-06-23T06:09:48Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 23 Jun 2005, Daniel Barkalow wrote:\n> \n> I bet I'm misunderstanding fuzz; what I actually mean is that, if a patch\n> applies after moving it, then regenerating it from the result would give\n> the a patch with different line numbers; if these affect the hash, the\n> author's tools will be sad.\n\nWhat GNU patch calls \"fuzz\" is how badly the context can \"not match\". A \n\"fuzz factor\" of one allows the patch to apply even if the \"outermost\" of \nthe context lines don't match up. See \"man patch\".\n\nWhat you talk about is what they (and I) call \"offset\", and yes, you must\nignore the line numbers when considering two patches identical, exactly\nbecause other patches may change their offsets.\n\nSo \"git-apply\" does apply patches that are offset from where the patch \nclaims (and the \"claimed position\" is really nothing more than a \"start \nsearching here\" parameter), but git-apply does not allow any fuzz.\n\n> > In fact, you could probably replace every run of contiguous whitespace\n> > with a single space, and then you'd not have to worry about whitespace\n> > differences either. That would be very simple to do, and quite workable: I\n> > certainly think it sounds more reliable than just hoping that people\n> > always pass on a \"patch ID\" in their emails..\n> \n> That's actually quite plausible. The only case it wouldn't handle is when\n> you actually discard parts, and I'm not sure at this point what other\n> people should see there.\n\nYes. One small note of warning: different \"diff\" algorithms may under some\n(mostly unlikely) circumstances result in different patches for the\ndifference between the same two files. So when comparin SHA1's of diffs\nthis way, you should also hopefully have the same diff generation\nalgorithm.\n\nThat's not likely to be a problem in practice, but it migh be something to \nkeep in mind as a _possible_ source of confusion, where a patch isn't \nrecognized only because it was generated differently from the one that we \ncompare against.\n\nIn practice, this can happen today with the \"-C\" and \"-M\" flags to diff,\nof course: two patches look different (and get different SHA1 values) just\nbecause one was generated with \"rename logic\" turned on and the other\nwasn't..\n\n> > Yeah. It probably works well in 99% of the cases to just do a simple\n> > \"export as patch\" + \"apply on top with old commit message, author and\n> > author-date\".\n> \n> I think that you'll get better results out of \"merge with top\" + \"commit\n> with old commit info, but not listing old commit as a parent\".\n\nIf I understand you correctly, that assumes that you followed the whole\nchain, though, and that there was no cherry-picking.\n\nI'd like to keep the door open here for cherry-picking or other \ntransformations (\"recreate tree _without_ that one commit\"), because it \nwould seem to also be a potentially good way to clean up history, not \njust move it forward, no?\n\n\t\tLinus\n"},{"id":"5179","messageId":"46a038f905062301363c3c1ea8@mail.gmail.com","threadId":"993","inReplyTo":"Pine.LNX.4.58.0506211452110.2353@ppc970.osdl.org","subject":"Re: Patch (apply) vs. Pull","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2005-06-23T08:36:03Z","receivedAt":"2005-06-23T08:36:03Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 6/22/05, Linus Torvalds <torvalds@osdl.org> wrote:\n> Btw, I'd like to help automate the 6-7 stage with a different kind of\n> merge logic.\n(...)\n>  - get the different HEAD info set up, and save the original head in\n>    ORIG_HEAD, the way \"git resolve\" does for real merges:\n> \n>         : ${GIT_DIR=.git}\n> \n>         orig=$(git-rev-parse HEAD)\n>         new=$(git-rev-parse FETCH_HEAD)\n>         common=$(git-merge-base $orig $new)\n> \n>         echo $orig > $GIT_DIR/ORIG_HEAD\n> \n>  - fast-forward to the new HEAD. We'll want to re-base everything off\n>    that. If that fails, exit out - we've got dirty state\n> \n>         git-read-tree -m -u $orig $new && exit 1\n> \n>  - for each commit that we had in our old tree but not in the common part,\n>    try to re-base it:\n> \n>         > FAILED_TO_CHERRYPICK\n>         for i in $(git-rev-list $orig ^$common)\n>         do\n>                 git-cherry-pick $i ||\n>                         (echo $i >> FAILED_TO_CHERRYPICK)\n>         done\n>         if [ -s FAILED_TO_CHERRYPICK ]; then\n>                 echo Some commits could not be cherry-picked, check by hand:\n>                 cat FAILED_TO_CHERRYPICK\n>         fi\n\nRe-base and replay local history is an approach I've been using\nsuccessfully with Arch (though it takes literally ages). Ideally, the\nprocess should be able to be restarted after one call to\ngit-cherry-pick fails. It is usually a handful of patches in a series\nof a few hundred that will break, usually because it's been fed\nupstream. You want to resolve the conflict and resume somehow.\n\n> and here the \"git-cherry-pick\" thing is just a script that basically takes\n> an old commit ID, and tries to re-apply it as a patch (with author data\n> and commit messages, of course) on top of the current head. It would\n> basically be nothing more than a \"git-diff-tree $1\" followed by tryign to\n> figure out whether it had already been applied or whether it can be\n> applied now.\n> \n> What do you think?\n\nSounds great. \n\nIt might be useful to provide it a \"skip\" list, so that it skips\napplying selected patches (that have presumably made it upstream).\n\nAnd perhaps --stop-at <commit-sha> so that if a large replay fails or\nyields a broken tree (not at the git level, but at the /does it\ncompile and run/ level), I can throw away the temporary repo where I'm\nworking and try again in shorter batches, stopping at \"strategical\"\npoints.\n\ncheers,\n\n\nmartin\n"},{"id":"5177","messageId":"46a038f9050623014755acb1c6@mail.gmail.com","threadId":"993","inReplyTo":"Pine.LNX.4.58.0506221504370.2353@ppc970.osdl.org","subject":"Re: Patch (apply) vs. Pull","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2005-06-23T08:47:03Z","receivedAt":"2005-06-23T08:47:03Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 6/23/05, Linus Torvalds <torvalds@osdl.org> wrote:\n> I've been doing unified diffs for a _loong_ time, and I edit patches in my\n> sleep. The rules for line numbers etc are really quite simple, and yes, I\n> do edit patches before I apply them.\n\nWe often do unified diff editing when dealing with merge conflicts. It\nisn't too hard once you've got the hang of it, usually the hard thing\nis resolving the conflict in the first place.\n\nEmacs has a diff editing mode that is really good:\nhttp://wiki.gnuarch.org/Process_20_2a_2erej_20files\n\ncheers,\n\n\nmartin\n"},{"id":"5182","messageId":"tnxr7et9su7.fsf@arm.com","threadId":"993","inReplyTo":"Pine.LNX.4.21.0506230025420.30848-100000@iabervon.org","subject":"Re: Patch (apply) vs. Pull","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2005-06-23T12:10:40Z","receivedAt":"2005-06-23T12:10:40Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"Daniel Barkalow <barkalow@iabervon.org> wrote:\n> I think that you'll get better results out of \"merge with top\" + \"commit\n> with old commit info, but not listing old commit as a parent\". At least,\n> that's what StGIT is doing, IIRC, and using merge instead of patch seems\n> like it'll make the remaining 1% a lot more pleasant.\n\nActually StGIT still lists the old commit as the 2nd parent since I\nwant to implement a log command which can also show only the commits\nagainst a single patch. If this 2nd parent would not be stored,\npushing a patch onto the stack when its base was changed would reset\nall the history for that patch.\n\nOf course, there are other ways of doing this like storing all the\ncommit ids in a file but I found this to be the simplest.\n\n-- \nCatalin\n\n"},{"id":"5188","messageId":"Pine.LNX.4.21.0506231149460.30848-100000@iabervon.org","threadId":"993","inReplyTo":"Pine.LNX.4.58.0506222258290.11175@ppc970.osdl.org","subject":"Re: Patch (apply) vs. Pull","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-06-23T16:45:45Z","receivedAt":"2005-06-23T16:45:45Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Wed, 22 Jun 2005, Linus Torvalds wrote:\n\n> On Thu, 23 Jun 2005, Daniel Barkalow wrote:\n> \n> > > In fact, you could probably replace every run of contiguous whitespace\n> > > with a single space, and then you'd not have to worry about whitespace\n> > > differences either. That would be very simple to do, and quite workable: I\n> > > certainly think it sounds more reliable than just hoping that people\n> > > always pass on a \"patch ID\" in their emails..\n> > \n> > That's actually quite plausible. The only case it wouldn't handle is when\n> > you actually discard parts, and I'm not sure at this point what other\n> > people should see there.\n> \n> Yes. One small note of warning: different \"diff\" algorithms may under some\n> (mostly unlikely) circumstances result in different patches for the\n> difference between the same two files. So when comparin SHA1's of diffs\n> this way, you should also hopefully have the same diff generation\n> algorithm.\n\nI think that, if we care much about the hashes of diffs, we should hash\nthe diff that's being applied, not hash a regenerated diff (unless, of\ncourse, the diff that's being applied has been modified in hash-relevant\nways, in which case it's not going to match anything anyway).\n\nGNU diff sometimes generates patches which are really terrible to try to\nread, because it finds some line of punctuation from a removed block that\nmatches a line in an added block and interleaves unrelated content. It\nwould be nice to not have to worry about confusion if there's a mismatch.\n\nWouldn't the only case where this would be a problem be if we had the\ncommitter apply the patch, generate a diff, hash it, and stick the hash in\nthe commit? The no-cache version has the diffs for hashing done by the\nsame person with the same program, and the hash-the-applied-patch version\nhas the hashes done on the same patch.\n\n> > > Yeah. It probably works well in 99% of the cases to just do a simple\n> > > \"export as patch\" + \"apply on top with old commit message, author and\n> > > author-date\".\n> > \n> > I think that you'll get better results out of \"merge with top\" + \"commit\n> > with old commit info, but not listing old commit as a parent\".\n> \n> If I understand you correctly, that assumes that you followed the whole\n> chain, though, and that there was no cherry-picking.\n\nI think that the whole-chain case is sufficiently common to make special\nand extra smooth; developers will be making their history forwards every\nday, and only cherry-picking on occasion.\n\nThis is also still in the developer's messy history, and I don't think\nthose commits are really worth much as history or organization (although\nthey're wonderful as checkpointing). The cherry-picking there will\ngenerally be content-based rather than commit-based, and will mostly be\npicking out hunks to form a clean patch sequence to replace the history.\n\n\t-Daniel\n*This .sig left intentionally blank*\n\n"},{"id":"5189","messageId":"Pine.LNX.4.21.0506231245560.30848-100000@iabervon.org","threadId":"993","inReplyTo":"tnxr7et9su7.fsf@arm.com","subject":"Re: Patch (apply) vs. Pull","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-06-23T17:05:03Z","receivedAt":"2005-06-23T17:05:03Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Thu, 23 Jun 2005, Catalin Marinas wrote:\n\n> Actually StGIT still lists the old commit as the 2nd parent since I\n> want to implement a log command which can also show only the commits\n> against a single patch. If this 2nd parent would not be stored,\n> pushing a patch onto the stack when its base was changed would reset\n> all the history for that patch.\n\nI think that it's important to avoid having the array of \"rebased the\npatch\" commits be reachable from the final series if that series is going\nto be merged into the mainline at the end.\n\nIf you want to keep the history of a patch, you should be able to do it by\nrebasing that history as well as the latest patch, so you'd get a\ntwo-parent commit with two rebased parents when you rebased a two-parent\ncommit.\n\n\t-Daniel\n*This .sig left intentionally blank*\n\n"},{"id":"5190","messageId":"Pine.LNX.4.58.0506231137440.11175@ppc970.osdl.org","threadId":"993","inReplyTo":"Pine.LNX.4.21.0506231149460.30848-100000@iabervon.org","subject":"Re: Patch (apply) vs. Pull","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-06-23T18:43:13Z","receivedAt":"2005-06-23T18:43:13Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 23 Jun 2005, Daniel Barkalow wrote:\n> \n> I think that, if we care much about the hashes of diffs, we should hash\n> the diff that's being applied, not hash a regenerated diff (unless, of\n> course, the diff that's being applied has been modified in hash-relevant\n> ways, in which case it's not going to match anything anyway).\n\nBut this whole algorithm depends on comparing two git commits, so we don't\nactually _have_ a diff: we must generate it ourselves from the commits we\nhave in the history (ie we'd compare the commit we're \"moving forward\"\nwith each commit that we're moving it forward past - in order to see\nwhether it's already been applied).\n\nNow, we control both of these patch generations, so in that sense it's \neasy to just make sure we generate both diffs the same way, but I just \nwanted to point this fact out.\n\n> Wouldn't the only case where this would be a problem be if we had the\n> committer apply the patch, generate a diff, hash it, and stick the hash in\n> the commit?\n\nRight, that would mean that we don't control the hash generation at both \npoints, and would make it fundamentally harder. But since the whole point \nis that we should be able to generate the ID _without_ it actually being \nstored away anywhere, this hash approach should work fine.\n\n> I think that the whole-chain case is sufficiently common to make special\n> and extra smooth; developers will be making their history forwards every\n> day, and only cherry-picking on occasion.\n\nI'm not convinced. I think a _lot_ of people would want to do re-ordering \nof patches, combining them, and cherry-picking them if they just had a \ngood way to do that.\n\nThat would then be a good way of cleaning up messy history too. Just prune \nthe old tree once you've moved it forward.\n\n\t\tLinus\n"},{"id":"5191","messageId":"Pine.LNX.4.21.0506231522080.30848-100000@iabervon.org","threadId":"993","inReplyTo":"Pine.LNX.4.58.0506231137440.11175@ppc970.osdl.org","subject":"Re: Patch (apply) vs. Pull","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-06-23T19:59:15Z","receivedAt":"2005-06-23T19:59:15Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Thu, 23 Jun 2005, Linus Torvalds wrote:\n\n> Right, that would mean that we don't control the hash generation at both \n> points, and would make it fundamentally harder. But since the whole point \n> is that we should be able to generate the ID _without_ it actually being \n> stored away anywhere, this hash approach should work fine.\n\n(\"We\" in this case being the developer checking whether the patch went in,\nnot the maintainer)\n\nWe'll need to see if the performance is okay this way, both in terms of\ntime spent searching for the patch you're checking on and in terms of\nrecognizing the patch as being the same. No point in designing anything\nmore complex until we determine if we can't just recognize it already.\n\n> > I think that the whole-chain case is sufficiently common to make special\n> > and extra smooth; developers will be making their history forwards every\n> > day, and only cherry-picking on occasion.\n> \n> I'm not convinced. I think a _lot_ of people would want to do re-ordering \n> of patches, combining them, and cherry-picking them if they just had a \n> good way to do that.\n\nOh, I think they'd want to do that. I just don't think they'd want to do\nit as often as they want to update their tree for changes in mainline,\njust because no one developer will do more work than the rest of the\ndevelopers combined. And it's worthwhile, because you need to use\ndiff/patch for the complex cases, and can use diff3 for the simple case,\nand you need diff3 if you want the system to treat \"everything in patch 5\nis already in the new base\" as success rather than conflict.\n\n(This is, incidentally, the case that drives me crazy about arch: if I\nmake a change in one working directory, copy that change into another\nworking directory, commit it from one of those directories, and update in\nthe other, I get a reject, and I then have to figure out if the changes \nwere actually the same or if one of them has further modifications.)\n\n\t-Daniel\n*This .sig left intentionally blank*\n\n"},{"id":"5192","messageId":"Pine.LNX.4.58.0506231510370.11175@ppc970.osdl.org","threadId":"993","inReplyTo":"Pine.LNX.4.21.0506231522080.30848-100000@iabervon.org","subject":"Re: Patch (apply) vs. Pull","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-06-23T22:20:36Z","receivedAt":"2005-06-23T22:20:36Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 23 Jun 2005, Daniel Barkalow wrote:\n>\n> On Thu, 23 Jun 2005, Linus Torvalds wrote:\n> > \n> > Right, that would mean that we don't control the hash generation at both \n> > points, and would make it fundamentally harder. But since the whole point \n> > is that we should be able to generate the ID _without_ it actually being \n> > stored away anywhere, this hash approach should work fine.\n> \n> (\"We\" in this case being the developer checking whether the patch went in,\n> not the maintainer)\n\nYes.\n\n> We'll need to see if the performance is okay this way, both in terms of\n> time spent searching for the patch you're checking on and in terms of\n> recognizing the patch as being the same. No point in designing anything\n> more complex until we determine if we can't just recognize it already.\n\nActually, this is a _very_ efficient check to do, because I'm just \nincredibly smart.\n\nWhat you do is to download the current git tree (give it a while to mirror \nout, actually), and you get a magic \"git-patch-id\" program.\n\nNow, the reason this is very efficient is magical. Let's say that you have\nmy tree as branch \"linus\", and you have your own tree (branch \"daniel\"),\nand you want to see what commits are in both (but are not the _same_\ncommit - you just wonder if they have the same diff). That's a big clue \nthat you should drop your copy, because I applied it as a diff.\n\nWhat you do is simply:\n\n\tgit-whatchanged -p linus..daniel | git-patch-id | sort > daniel-patch-id\n\tgit-whatchanged -p daniel..linus | git-patch-id | sort > linus-patch-id\n\tjoin -j 1 linus-patch-id daniel-patch-id\n\nand you're done. You've just created a list of commits that have the same \npatch ID (and it will list the patch ID _and_ the two commit ID's, just \nto be really nice about it).\n\nIt's all totally linear in number of patches involved (yeah, the \"sort\" is\nobviously reall NlogN, and technically the git-rev-list between the two\ntrees _could_ be more than linear, but in practice they are very cheap and\nvery close to linear anyway).\n\nIt's also obviously totally untested, but hey, I always write perfect\ncode, so what could _possibly_ go wrong..\n\n\t\tLinus\n"},{"id":"5193","messageId":"Pine.LNX.4.58.0506231523020.11175@ppc970.osdl.org","threadId":"993","inReplyTo":"Pine.LNX.4.58.0506231510370.11175@ppc970.osdl.org","subject":"Re: Patch (apply) vs. Pull","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-06-23T22:49:08Z","receivedAt":"2005-06-23T22:49:08Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 23 Jun 2005, Linus Torvalds wrote:\n> \n> It's also obviously totally untested, but hey, I always write perfect\n> code, so what could _possibly_ go wrong..\n\nActually, for once it actually does work.\n\nDoing this for the whole current git kernel history shows the following\npatch ID's that are duplicates:\n\n - fix ia64 syscall auditing:\n\t0d9a1c0b1d4009f81f1c3d558961cc1eaf89c43d 3ac3ed555bec5b1f92bb22cb94823a0e99d0f320\n\t0d9a1c0b1d4009f81f1c3d558961cc1eaf89c43d 446b8831f5acf2076fa58a66286789eb84f3df2c\n\n - remove outdated print_* functions:\n\t1a830d81e7580b55eb0d445a5bf43920e1dba211 1409277c4aad2e87ad27b2b8a6901ce78eaf8081\n\t1a830d81e7580b55eb0d445a5bf43920e1dba211 db9dff366ba78085d0323364fadbf09bec0e77ee\n\n - zfcp: add point-2-point support:\n\t3969795b9b61425ef7e7ac52e9576203dc1ca71a 6f71d9bc025b02a8cbc2be83b0226a7043a507a5\n\t3969795b9b61425ef7e7ac52e9576203dc1ca71a 91bbfbda8d41f834c70c47d6f8c95245c90019e5\n\n - ppc32: add 405EP cpu_spec entry:\n\t59a8f295cf4c44cae74db41699392dc22db64df1 7fbdf1a23be1837b8bc5bcec096015ca99e00aa7\n\t59a8f295cf4c44cae74db41699392dc22db64df1 ad95d6098dd1e94a09d2a1fdf39fd8281fcd8958\n\t59a8f295cf4c44cae74db41699392dc22db64df1 beb9e1c3f32a0f878765c7c1142f91083739c5bd\n\n - Convert i2o to compat_ioctl:\n\t6ab2bc457d0a736d97f26f2ca75666bb981fdc42 83363ea074504f9005e28cd6209923637bb74de5\n\t6ab2bc457d0a736d97f26f2ca75666bb981fdc42 f4c2c15b930b23edaa633b09fe3f4c01b4ecce9f\n\n - ppc32: Fix Alsa PowerMac driver on old machines:\n\t7c82fcb20679f5c24c8db37b6dc554bf841744e9 5218064c885af5c49e380d09d54f3cc86891a580\n\t7c82fcb20679f5c24c8db37b6dc554bf841744e9 9ae250d175e1cbff82223ce2c07897c790c5b948\n\n - scsi: remove unused scsi_cmnd->internal_timeout field\n\t883a1e3ca52a071eaf9d53e66d13b250c6d60942 97665e9c22991401dc56968619c6b8b9c09f3268\n\t883a1e3ca52a071eaf9d53e66d13b250c6d60942 d3a933dc9851e74581f9f4c8e703e77901ae8d01\n\n - scsi: remove meaningless scsi_cmnd->serial_number_at_timeout field:\n\t8d3c15861cc08388e610940506255d3a19109aee 84011ae88da62a20b3ae7b48e2ae3b1ef0fc810a\n\t8d3c15861cc08388e610940506255d3a19109aee c6295cdf656de63d6d1123def71daba6cd91939c\n\n - kill old EH constants:\n\t9b0f17e44f99618902fa0cdc5cd73711060f3650 0db7157ca47e21c7623a59e710b807ad06fce161\n\t9b0f17e44f99618902fa0cdc5cd73711060f3650 2bc474c3646efba67bdc83b7fc7d8ee7562e0106\n\n - input: Fix fast scrolling scancodes in atkbd.c:\n\tbb6b1e4d2d979e1cccf96d0dd494f608d5143bee 5212dd58e67e4b8009107d69a9de45dd2e687496\n\tbb6b1e4d2d979e1cccf96d0dd494f608d5143bee 7d6064d44bc79e328f2794ee7322ba2676511e2b\n\n - scsi: add DID_REQUEUE to the error handling:\n\tc62473f1990c475b087fee7280a1b2e9b9589bc5 686579d95d48c713bdb7008cc76af8398219e687\n\tc62473f1990c475b087fee7280a1b2e9b9589bc5 bf341919dbc1fbcbb565fb3224c840760ebd9f85\n\n - consolidate timeout defintions in scsi.h:\n\td56aa0d90bced261ddf3b58038fca3cbff59a189 0890d74f295be849032fd4390ee00422dfda83b1\n\td56aa0d90bced261ddf3b58038fca3cbff59a189 b6651129cc27d56a9cbefcb5f713cea7706fd6b7\n\n - kill gratitious includes of major.h:\n\te938d763a9c231acbf93f1140c911cbec447c89d 5523662c4cd585b892811d7bb3e25d9a787e19b3\n\te938d763a9c231acbf93f1140c911cbec447c89d b453257f057b834fdf9f4a6ad6133598b79bd982\n\n - drivers/scsi/sym53c416.c: fix a wrong check:\n\teb2d067160e40137cd00590e59e800dd09c4f62f 380c3877ae5de888cfb7a59990b9aee5a415295f\n\teb2d067160e40137cd00590e59e800dd09c4f62f b6f0b0d016a254ff583fec26f2c9e21c1ae2fdf3\n\n - ultrastor: fix compile failure:\n\ted19cee5e4439c92e4e711fe1c10569b58415c46 4e33bd874bce8b3df2ab52538db59730196383c3\n\ted19cee5e4439c92e4e711fe1c10569b58415c46 69aa3f71580990f39e387d96ed1001d2f5fb04b1\n\n - qla trivial iomem annotation:\n\tff16fe82338d2dd7d8baf6a3b38780e0eac2b1f0 766f2fa170e65948053b06c6106c8dc8526c3e14\n\tff16fe82338d2dd7d8baf6a3b38780e0eac2b1f0 93fc4294fc112ce4e518a3f62dea8681dc39d9cf\n\nwhere the first number is the patch ID, the the second number is the \ncommit ID.\n\nWhat's interesting to note here is the following:\n\n - it actually did find duplicates in the current kernel that had just \n   merged perfectly and come in through two different trees.\n\n   It's also interesting to note that while most of them had largely the\n   same commit message (ie they clearly got applied from the same emailed\n   diff), the algorithm doesn't even look at that one, and thus the fact\n   that some had extra comments (\"I have tested this patch and have seen\n   no problems with it.\") others had not just different sign-offs (due to \n   the different paths they took), but different authors noted.\n\n   Ie this really doesn't care at all about how the patch came there, it \n   just notices that the patch is identical to some other patch.\n\n - it didn't have a single false positive (the above is the full list of \n   duplicate patch ID's - I just did a\n\n\tgit-whatchanged -p | git-patch-id | LANG=C sort > sorted-patch-list\n\n   followed by\n\n\tcut -d' ' -f1 sorted-patch-list | uniq -d | join -j 1 - sorted-patch-list\n\n   and then when you have that list, you can check the commits themselves \n   with\n\n\tcut -d' ' -f2 dup-list | git-diff-tree --pretty -p --stdin | less -S\n\n   and verify the output.\n\n - it actually found the patch that got incorrectly applied _three_times_ \n   (\"ppc32: add 405EP cpu_spec entry\") because it continued to apply, and\n   thus Andrew's scripts didn't notice it.\n\nIn other words, this \"check patch ID's\" thing is not only efficient, it\nactually seems to work. It literally checked the last 2+ months of kernel\nhistory (2788 patches) for duplicate patches in just under a minute, and\nmight be useful to Andrew etc as a way to see \"yup, that patch got\napplied\".\n\nDoing the same for just the difference between two branches is pretty much\ninstantaneous. You can basically check ~50 patches a second using this.\n\n\t\tLinus\n"},{"id":"5196","messageId":"7v4qbofym7.fsf_-_@assigned-by-dhcp.cox.net","threadId":"993","inReplyTo":"Pine.LNX.4.58.0506211452110.2353@ppc970.osdl.org","subject":"[PATCH 0/3] Rebasing for \"individual developer\" usage","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-06-23T23:21:36Z","receivedAt":"2005-06-23T23:21:36Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":">>>>> \"LT\" == Linus Torvalds <torvalds@osdl.org> writes:\n\nLT> Something like this...\nLT> What do you think?\n\nI'll be sending these three patches as my answer to that question.\n\n    [PATCH 1/3] git-commit-script: get commit message from an existing one.\n    [PATCH 2/3] git-cherry: find commits not merged upstream.\n    [PATCH 3/3] git-rebase-script: rebase local commits to new upstream head.\n\n"},{"id":"5200","messageId":"7vfyv8ejrn.fsf_-_@assigned-by-dhcp.cox.net","threadId":"993","inReplyTo":"7v4qbofym7.fsf_-_@assigned-by-dhcp.cox.net","subject":"[PATCH 1/3] git-commit-script: get commit message from an existing one.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-06-23T23:27:40Z","receivedAt":"2005-06-23T23:27:40Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"With -m flag specified, git-commit-script takes the commit\nmessage along with author information from an existing commit.\n\nSigned-off-by: Junio C Hamano <junkio@cox.net>\n---\n*** Linus, I suspect that date.c mishandles the raw date; I am\n*** consistently getting 7 hours off and my machine runs in\n*** US/Pacific (-0700) timezone.\n\n git-commit-script |   75 +++++++++++++++++++++++++++++++++++++++++++++++------\n 1 files changed, 67 insertions(+), 8 deletions(-)\n\ndiff --git a/git-commit-script b/git-commit-script\n--- a/git-commit-script\n+++ b/git-commit-script\n@@ -1,12 +1,37 @@\n #!/bin/sh\n+#\n+# Copyright (c) 2005 Linus Torvalds\n+#\n+\n+usage () {\n+    echo 'git commit [-m existing-commit] [<path>...]'\n+    exit 1\n+}\n+\n : ${GIT_DIR=.git}\n-if [ ! -d $GIT_DIR ]; then\n+if [ ! -d \"$GIT_DIR\" ]; then\n \techo Not a git directory 1>&2\n \texit 1\n fi\n+while case \"$#\" in 0) break ;; esac\n+do\n+    case \"$1\" in\n+    -m) shift\n+        case \"$#\" in\n+\t0) usage ;;\n+\t*) use_commit=`git-rev-parse \"$1\"` ||\n+\t   exit ;;\n+\tesac\n+\t;;\n+    *)  break\n+        ;;\n+    esac\n+    shift\n+done\n+\n git-update-cache -q --refresh -- \"$@\" || exit 1\n PARENTS=\"-p HEAD\"\n-if [ ! -r $GIT_DIR/HEAD ]; then\n+if [ ! -r \"$GIT_DIR/HEAD\" ]; then\n \tif [ -z \"$(git-ls-files)\" ]; then\n \t\techo Nothing to commit 1>&2\n \t\texit 1\n@@ -20,7 +45,7 @@ if [ ! -r $GIT_DIR/HEAD ]; then\n \t) > .editmsg\n \tPARENTS=\"\"\n else\n-\tif [ -f $GIT_DIR/MERGE_HEAD ]; then\n+\tif [ -f \"$GIT_DIR/MERGE_HEAD\" ]; then\n \t\techo \"#\"\n \t\techo \"# It looks like your may be committing a MERGE.\"\n \t\techo \"# If this is not correct, please remove the file\"\n@@ -28,8 +53,38 @@ else\n \t\techo \"# and try again\"\n \t\techo \"#\"\n \t\tPARENTS=\"-p HEAD -p MERGE_HEAD\"\n-\tfi > .editmsg\n-\tgit-status-script >> .editmsg\n+\telif test \"$use_commit\" != \"\"\n+\tthen\n+\t\tpick_author_script='\n+\t\t/^author /{\n+\t\t\th\n+\t\t\ts/^author \\([^<]*\\) <[^>]*> .*$/\\1/\n+\t\t\ts/'\\''/'\\''\\'\\'\\''/g\n+\t\t\ts/.*/GIT_AUTHOR_NAME='\\''&'\\''/p\n+\n+\t\t\tg\n+\t\t\ts/^author [^<]* <\\([^>]*\\)> .*$/\\1/\n+\t\t\ts/'\\''/'\\''\\'\\'\\''/g\n+\t\t\ts/.*/GIT_AUTHOR_EMAIL='\\''&'\\''/p\n+\n+\t\t\tg\n+\t\t\ts/^author [^<]* <[^>]*> \\(.*\\)$/\\1/\n+\t\t\ts/'\\''/'\\''\\'\\'\\''/g\n+\t\t\ts/.*/GIT_AUTHOR_DATE='\\''&'\\''/p\n+\n+\t\t\tq\n+\t\t}\n+\t\t'\n+\t\tset_author_env=`git-cat-file commit \"$use_commit\" |\n+\t\tsed -ne \"$pick_author_script\"`\n+\t\teval \"$set_author_env\"\n+\t\texport GIT_AUTHOR_NAME\n+\t\texport GIT_AUTHOR_EMAIL\n+\t\texport GIT_AUTHOR_DATE\n+\t\tgit-cat-file commit \"$use_commit\" |\n+\t\tsed -e '1,/^$/d'\n+\tfi >.editmsg\n+\tgit-status-script >>.editmsg\n fi\n if [ \"$?\" != \"0\" ]\n then\n@@ -37,13 +92,17 @@ then\n \trm .editmsg\n \texit 1\n fi\n-${VISUAL:-${EDITOR:-vi}} .editmsg\n+case \"$use_commit\" in\n+'')\n+\t${VISUAL:-${EDITOR:-vi}} .editmsg\n+\t;;\n+esac\n grep -v '^#' < .editmsg | git-stripspace > .cmitmsg\n [ -s .cmitmsg ] && \n \ttree=$(git-write-tree) &&\n \tcommit=$(cat .cmitmsg | git-commit-tree $tree $PARENTS) &&\n-\techo $commit > $GIT_DIR/HEAD &&\n-\trm -f -- $GIT_DIR/MERGE_HEAD\n+\techo $commit > \"$GIT_DIR/HEAD\" &&\n+\trm -f -- \"$GIT_DIR/MERGE_HEAD\"\n ret=\"$?\"\n rm -f .cmitmsg .editmsg\n exit \"$ret\"\n------------\n\n"},{"id":"5201","messageId":"7vaclgejqc.fsf_-_@assigned-by-dhcp.cox.net","threadId":"993","inReplyTo":"7v4qbofym7.fsf_-_@assigned-by-dhcp.cox.net","subject":"[PATCH 2/3] git-cherry: find commits not merged upstream.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-06-23T23:28:27Z","receivedAt":"2005-06-23T23:28:27Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"This script helps the git-rebase script by finding commits that\nhave not been merged upstream.\n\nSigned-off-by: Junio C Hamano <junkio@cox.net>\n---\n\n Makefile   |    2 +\n git-cherry |   90 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++\n 2 files changed, 91 insertions(+), 1 deletions(-)\n create mode 100755 git-cherry\n\ndiff --git a/Makefile b/Makefile\n--- a/Makefile\n+++ b/Makefile\n@@ -25,7 +25,7 @@ SCRIPTS=git git-apply-patch-script git-m\n \tgit-deltafy-script git-fetch-script git-status-script git-commit-script \\\n \tgit-log-script git-shortlog git-cvsimport-script git-diff-script \\\n \tgit-reset-script git-add-script git-checkout-script git-clone-script \\\n-\tgitk\n+\tgitk git-cherry\n \n PROG=   git-update-cache git-diff-files git-init-db git-write-tree \\\n \tgit-read-tree git-commit-tree git-cat-file git-fsck-cache \\\ndiff --git a/git-cherry b/git-cherry\nnew file mode 100755\n--- /dev/null\n+++ b/git-cherry\n@@ -0,0 +1,90 @@\n+#!/bin/sh\n+#\n+# Copyright (c) 2005 Junio C Hamano.\n+#\n+\n+usage=\"usage: $0 \"'<upstream> [<head>]\n+\n+             __*__*__*__*__> <upstream>\n+            /\n+  fork-point\n+            \\__+__+__+__+__+__+__+__> <head>\n+\n+Each commit between the fork-point and <head> is examined, and\n+compared against the change each commit between the fork-point and\n+<upstream> introduces.  If the change does not seem to be in the\n+upstream, it is shown on the standard output.\n+\n+The output is intended to be used as:\n+\n+    OLD_HEAD=$(git-rev-parse HEAD)\n+    git-rev-parse linus >${GIT_DIR-.}/HEAD\n+    git-cherry linus OLD_HEAD |\n+    while read commit\n+    do\n+        GIT_EXTERNAL_DIFF=git-apply-patch-script git-diff-tree -p \"$commit\" &&\n+\tgit-commit-script -m \"$commit\"\n+    done\n+'\n+\n+case \"$#\" in\n+1) linus=`git-rev-parse \"$1\"` &&\n+   junio=`git-rev-parse HEAD` || exit\n+   ;;\n+2) linus=`git-rev-parse \"$1\"` &&\n+   junio=`git-rev-parse \"$2\"` || exit\n+   ;;\n+*) echo >&2 \"$usage\"; exit 1 ;;\n+esac\n+\n+# Note that these list commits in reverse order;\n+# not that the order in inup matters...\n+inup=`git-rev-list ^$junio $linus` &&\n+ours=`git-rev-list $junio ^$linus` || exit\n+\n+tmp=.cherry-tmp$$\n+patch=$tmp-patch\n+diff=$tmp-diff\n+mkdir $patch\n+trap \"rm -rf $tmp-*\" 0 1 2 3 15\n+\n+_x40='[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]'\n+_x40=\"$_x40$_x40$_x40$_x40$_x40$_x40$_x40$_x40\"\n+\n+for c in $inup $ours\n+do\n+\tgit-diff-tree -p $c |\n+\tsed -e \"/^$_x40 (from $_x40)\\$/d;/^--- /d;/^+++ /d;/^@@ /d\" >$patch/$c\n+\tgit-diff-tree -r $c |\n+\tsed -e \"/^$_x40 (from $_x40)\\$/d;s/ $_x40 $_x40 / X X /\" >$patch/$c.s\n+done\n+\n+LF='\n+'\n+O=\n+for c in $ours\n+do\n+\tfound=\n+\tfor d in $inup\n+\tdo\n+\t\tcmp $patch/$c.s $patch/$d.s >/dev/null ||\n+\t\tcontinue\n+\n+\t\tdiff --unified=0 $patch/$c $patch/$d >$diff\n+\t\tcmp /dev/null $diff >/dev/null && {\n+\t\t\tfound=t\n+\t\t\tbreak\n+\t\t}\n+\tdone\n+\tcase \"$found,$O\" in\n+\tt,*)\t;;\n+\t,)\n+\t\tO=\"$c\" ;;\n+\t,*)\n+\t\tO=\"$c$LF$O\" ;;\n+\tesac\n+done\n+case \"$O\" in\n+'') ;;\n+*)  echo \"$O\" ;;\n+esac\n------------\n\n"},{"id":"5202","messageId":"7v4qboejp6.fsf_-_@assigned-by-dhcp.cox.net","threadId":"993","inReplyTo":"7v4qbofym7.fsf_-_@assigned-by-dhcp.cox.net","subject":"[PATCH 3/3] git-rebase-script: rebase local commits to new upstream head.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-06-23T23:29:09Z","receivedAt":"2005-06-23T23:29:09Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Using git-cherry, forward port local commits missing from the\nnew upstream head.  This depends on \"-m\" flag support in\ngit-commit-script.\n\nSigned-off-by: Junio C Hamano <junkio@cox.net>\n---\n\n Makefile          |    2 +-\n git-rebase-script |   46 ++++++++++++++++++++++++++++++++++++++++++++++\n 2 files changed, 47 insertions(+), 1 deletions(-)\n create mode 100755 git-rebase-script\n\ndiff --git a/Makefile b/Makefile\n--- a/Makefile\n+++ b/Makefile\n@@ -25,7 +25,7 @@ SCRIPTS=git git-apply-patch-script git-m\n \tgit-deltafy-script git-fetch-script git-status-script git-commit-script \\\n \tgit-log-script git-shortlog git-cvsimport-script git-diff-script \\\n \tgit-reset-script git-add-script git-checkout-script git-clone-script \\\n-\tgitk git-cherry\n+\tgitk git-cherry git-rebase-script\n \n PROG=   git-update-cache git-diff-files git-init-db git-write-tree \\\n \tgit-read-tree git-commit-tree git-cat-file git-fsck-cache \\\ndiff --git a/git-rebase-script b/git-rebase-script\nnew file mode 100755\n--- /dev/null\n+++ b/git-rebase-script\n@@ -0,0 +1,46 @@\n+#!/bin/sh\n+#\n+# Copyright (c) 2005 Junio C Hamano.\n+#\n+\n+usage=\"usage: $0 \"'<upstream> [<head>]\n+\n+Uses output from git-cherry to rebase local commits to the new head of\n+upstream tree.'\n+\n+: ${GIT_DIR=.git}\n+\n+case \"$#\" in\n+1) linus=`git-rev-parse \"$1\"` &&\n+   junio=`git-rev-parse HEAD` || exit\n+   ;;\n+2) linus=`git-rev-parse \"$1\"` &&\n+   junio=`git-rev-parse \"$2\"` || exit\n+   ;;\n+*) echo >&2 \"$usage\"; exit 1 ;;\n+esac\n+\n+git-read-tree -m -u $junio $linus &&\n+echo \"$linus\" >\"$GIT_DIR/HEAD\" || exit\n+\n+tmp=.rebase-tmp$$\n+fail=$tmp-fail\n+trap \"rm -rf $tmp-*\" 0 1 2 3 15\n+\n+>$fail\n+\n+git-cherry $linus $junio |\n+while read commit\n+do\n+\tS=`cat \"$GIT_DIR/HEAD\"` &&\n+        GIT_EXTERNAL_DIFF=git-apply-patch-script git-diff-tree -p $commit &&\n+\tgit-commit-script -m \"$commit\" || {\n+\t\techo $commit >>$fail\n+\t\tgit-read-tree --reset -u $S\n+\t}\n+done\n+if test -s $fail\n+then\n+\techo Some commits could not be rebased, check by hand:\n+\tcat $fail\n+fi\n------------\n\n"},{"id":"5221","messageId":"tnxvf4350th.fsf@arm.com","threadId":"993","inReplyTo":"Pine.LNX.4.21.0506231245560.30848-100000@iabervon.org","subject":"Re: Patch (apply) vs. Pull","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2005-06-24T13:41:46Z","receivedAt":"2005-06-24T13:41:46Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"Daniel Barkalow <barkalow@iabervon.org> wrote:\n> I think that it's important to avoid having the array of \"rebased the\n> patch\" commits be reachable from the final series if that series is going\n> to be merged into the mainline at the end.\n\nTrue. I will remove that. Any commit will have the new base of the\npatch as a parent.\n\n> If you want to keep the history of a patch, you should be able to do it by\n> rebasing that history as well as the latest patch, so you'd get a\n> two-parent commit with two rebased parents when you rebased a two-parent\n> commit.\n\nI can have two commits, one of them accessible via HEAD and the other\nstored somewhere under .git/patches. The latter is just a normal\ncommit where the parent is the current HEAD. This will not be\ngenerated when the patch is re-based, but only when a patch is\nmodified.\n\n-- \nCatalin\n\n"}]}