{"thread":{"id":"8818","subject":"being nice to patch(1)","startedAt":"2007-07-02T19:54:50Z","lastAt":"2007-07-06T18:08:10Z","messageCount":32,"participants":["Andrew Morton","Linus Torvalds","Junio C Hamano","Johannes Schindelin","Paolo Ciarrocchi","David Kastrup","Andreas Gruenbacher","Theodore Tso","Paul Eggert"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"46270","messageId":"20070702125450.28228edd.akpm@linux-foundation.org","threadId":"8818","inReplyTo":null,"subject":"being nice to patch(1)","fromName":"Andrew Morton","fromEmail":"akpm@linux-foundation.org","sentAt":"2007-07-02T19:54:50Z","receivedAt":"2007-07-02T19:54:50Z","isPatch":false,"sender":{"key":"akpm@linux-foundation.org","avatar":null},"body":"\nJames's current git-scsi-misc has this commit in it:\n\n\ncommit a16efc1cbf0a9e5ea9f99ae98fb774b60d05c35b\nAuthor: Kars de Jong \nDate: Sun Jun 17 14:47:08 2007 +0200\n\n[SCSI] 53c700: Amiga 4000T NCR53c710 SCSI\n \n New driver for the Amiga 4000T built-in NCR53c710 SCSI controller, using the\n 53c700 SCSI core.\n \n Signed-off-by: Geert Uytterhoeven \n Signed-off-by: James Bottomley \n\n\nWhen one pulls that diff out of git with `git-show' or whatever, it doesn't\nwork - patch(1) has a heart attack over the \"53c700\":\n\n\n|commit f98754960a9b25057ad5f249f877b3d6fab889ce\n|Author: FUJITA Tomonori \n|Date: Mon May 14 20:25:31 2007 +0900\n|\n| [SCSI] hptiop: convert to use the data buffer accessors\n| \n| - remove the unnecessary map_single path.\n| \n| - convert to use the new accessors for the sg lists and the\n| parameters.\n| \n| Jens Axboe did the for_each_sg cleanup.\n| \n| Signed-off-by: FUJITA Tomonori \n| Acked-by: HighPoint Linux Team \n| Signed-off-by: James Bottomley \n|\n|commit a16efc1cbf0a9e5ea9f99ae98fb774b60d05c35b\n|Author: Kars de Jong \n|Date: Sun Jun 17 14:47:08 2007 +0200\n|\n| [SCSI] 53c700: Amiga 4000T NCR53c710 SCSI\n| \n| New driver for the Amiga 4000T built-in NCR53c710 SCSI controller, using the\n--------------------------\nFile to patch: \n\n\n\n\nThis I assume is because ^[ ]*c is a magic marker for\ncontextual diffs.\n\nSo... if someone is feeling really, really, really bored one day, it would\nbe nice to teach git to somehow escape such patch-magic-patterns in the\nchangelog when emitting plain old patches.\n"},{"id":"46279","messageId":"alpine.LFD.0.98.0707021409510.9434@woody.linux-foundation.org","threadId":"8818","inReplyTo":"20070702125450.28228edd.akpm@linux-foundation.org","subject":"Re: being nice to patch(1)","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-07-02T21:16:16Z","receivedAt":"2007-07-02T21:16:16Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 2 Jul 2007, Andrew Morton wrote:\n> \n> James's current git-scsi-misc has this commit in it:\n> \n> commit a16efc1cbf0a9e5ea9f99ae98fb774b60d05c35b\n> Author: Kars de Jong \n> Date: Sun Jun 17 14:47:08 2007 +0200\n> \n> [SCSI] 53c700: Amiga 4000T NCR53c710 SCSI\n> \n> New driver for the Amiga 4000T built-in NCR53c710 SCSI controller, using the\n> 53c700 SCSI core.\n> \n> Signed-off-by: Geert Uytterhoeven \n> Signed-off-by: James Bottomley \n> \n> \n> When one pulls that diff out of git with `git-show' or whatever, it doesn't\n> work - patch(1) has a heart attack over the \"53c700\":\n\nThere's really nothing git can do about this, this is a patch oddity about \nthe free-form message. A really strange one too, because the line is \nliterally four spaces followed by the 53c700, and the thing is, that's not \neven a valid olf-fashioned patch (_without_ the four spaces, I could see \nthat \"patch\" might think that it's a really old ed-\n\nI think you have two options:\n\n - tell patch to take it as a unified diff:\n\n\tgit show | patch -p1 -u\n\n should work, since patch won't be trying to figure out what kind of \n diff it is, and won't think that the 53c700 is some kind of odd ed \n script.\n\n - suppress the free-form messages, by using (for example)\n\n\tgit show --pretty=oneline | patch -p1\n\n and now \"patch\" doesn't get any random commit message except for the \n first line (which always starts with the SHA1) and hopefully cannot \n _possibly_ interpret that to be some strange patch format.\n\nOr, of course, just use \"git-apply\" instead of patch to apply the thing.\n\n\t\t\tLinus\n"},{"id":"46281","messageId":"20070702142557.eba61ccd.akpm@linux-foundation.org","threadId":"8818","inReplyTo":"alpine.LFD.0.98.0707021409510.9434@woody.linux-foundation.org","subject":"Re: being nice to patch(1)","fromName":"Andrew Morton","fromEmail":"akpm@linux-foundation.org","sentAt":"2007-07-02T21:25:57Z","receivedAt":"2007-07-02T21:25:57Z","isPatch":false,"sender":{"key":"akpm@linux-foundation.org","avatar":null},"body":"On Mon, 2 Jul 2007 14:16:16 -0700 (PDT)\nLinus Torvalds wrote:\n\n> \n> \n> On Mon, 2 Jul 2007, Andrew Morton wrote:\n> > \n> > James's current git-scsi-misc has this commit in it:\n> > \n> > commit a16efc1cbf0a9e5ea9f99ae98fb774b60d05c35b\n> > Author: Kars de Jong \n> > Date: Sun Jun 17 14:47:08 2007 +0200\n> > \n> > [SCSI] 53c700: Amiga 4000T NCR53c710 SCSI\n> > \n> > New driver for the Amiga 4000T built-in NCR53c710 SCSI controller, using the\n> > 53c700 SCSI core.\n> > \n> > Signed-off-by: Geert Uytterhoeven \n> > Signed-off-by: James Bottomley \n> > \n> > \n> > When one pulls that diff out of git with `git-show' or whatever, it doesn't\n> > work - patch(1) has a heart attack over the \"53c700\":\n> \n> There's really nothing git can do about this, this is a patch oddity about \n> the free-form message. A really strange one too, because the line is \n> literally four spaces followed by the 53c700, and the thing is, that's not \n> even a valid olf-fashioned patch (_without_ the four spaces, I could see \n> that \"patch\" might think that it's a really old ed-\n> \n> I think you have two options:\n> \n> - tell patch to take it as a unified diff:\n> \n> \tgit show | patch -p1 -u\n> \n> should work, since patch won't be trying to figure out what kind of \n> diff it is, and won't think that the 53c700 is some kind of odd ed \n> script.\n\nyup, `patch -u' fixes it up.\n\n> - suppress the free-form messages, by using (for example)\n> \n> \tgit show --pretty=oneline | patch -p1\n> \n> and now \"patch\" doesn't get any random commit message except for the \n> first line (which always starts with the SHA1) and hopefully cannot \n> _possibly_ interpret that to be some strange patch format.\n> \n> Or, of course, just use \"git-apply\" instead of patch to apply the thing.\n> \n\nThing is, changelog-followed-by-diff is a fairly standard format used by\nquilt and other such toys.\n\nHopefully quilt is using -u so it won't encounter this oddity.\n"},{"id":"46284","messageId":"alpine.LFD.0.98.0707021436300.9434@woody.linux-foundation.org","threadId":"8818","inReplyTo":"20070702142557.eba61ccd.akpm@linux-foundation.org","subject":"Re: being nice to patch(1)","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-07-02T21:40:36Z","receivedAt":"2007-07-02T21:40:36Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 2 Jul 2007, Andrew Morton wrote:\n> \n> Thing is, changelog-followed-by-diff is a fairly standard format used by\n> quilt and other such toys.\n\nSure. And if a tool ends up eating the changelog as a diff, then that tool \nis broken. I really do think that this is a \"patch\" bug - I really don't \nthink that that was a valid traditional diff with the four spaces at the \nhead of the line.\n\nOf course, if the changelog-followed-by-diff doesn't have any indentation \nor escaping at all, the changelog entry itself *could* actually have a \nreal unified diff in it, and the tool would be unable to tell where the \nactual patch starts.\n\nBut at least \"git show\" and friends indent the changelog on purpose, \nexactly so that there is never any chance that there could be any real \nambiguity, and this really was a \"patch\" bug as far as I can tell. \nHappily, one that is easy to work around, by just telling patch to always \nconsider the patch a unified diff.\n\n\t\t\tLinus\n"},{"id":"46285","messageId":"20070702145601.a0dcef0f.akpm@linux-foundation.org","threadId":"8818","inReplyTo":"alpine.LFD.0.98.0707021436300.9434@woody.linux-foundation.org","subject":"Re: being nice to patch(1)","fromName":"Andrew Morton","fromEmail":"akpm@linux-foundation.org","sentAt":"2007-07-02T21:56:01Z","receivedAt":"2007-07-02T21:56:01Z","isPatch":false,"sender":{"key":"akpm@linux-foundation.org","avatar":null},"body":"On Mon, 2 Jul 2007 14:40:36 -0700 (PDT)\nLinus Torvalds wrote:\n\n> \n> \n> On Mon, 2 Jul 2007, Andrew Morton wrote:\n> > \n> > Thing is, changelog-followed-by-diff is a fairly standard format used by\n> > quilt and other such toys.\n> \n> Sure. And if a tool ends up eating the changelog as a diff, then that tool \n> is broken. I really do think that this is a \"patch\" bug - I really don't \n> think that that was a valid traditional diff with the four spaces at the \n> head of the line.\n> \n> Of course, if the changelog-followed-by-diff doesn't have any indentation \n> or escaping at all, the changelog entry itself *could* actually have a \n> real unified diff in it, and the tool would be unable to tell where the \n> actual patch starts.\n\nerk, yes, sometimes people do like to quote a hunk of diff in the changelog\nand yes, hell doth break loose.\n\n> But at least \"git show\" and friends indent the changelog on purpose, \n> exactly so that there is never any chance that there could be any real \n> ambiguity, and this really was a \"patch\" bug as far as I can tell. \n> Happily, one that is easy to work around, by just telling patch to always \n> consider the patch a unified diff.\n\nI'm afraid indenting the changelog with leading spaces doesn't help -\npatch(1) still tries to apply the diff.\n\nI guess quilt-and-friends could (should) strip away all text prior to the\nfirst ^--- before feeding to patch(1). That would reliably remove all\ngit changelog text.\n"},{"id":"46306","messageId":"alpine.LFD.0.98.0707021713200.9434@woody.linux-foundation.org","threadId":"8818","inReplyTo":"20070702145601.a0dcef0f.akpm@linux-foundation.org","subject":"Re: being nice to patch(1)","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-07-03T00:28:41Z","receivedAt":"2007-07-03T00:28:41Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 2 Jul 2007, Andrew Morton wrote:\n> \n> I'm afraid indenting the changelog with leading spaces doesn't help -\n> patch(1) still tries to apply the diff.\n\nOh wow. I didn't believe you, so I decided to test.\n\nI shouldn't have doubted you.\n\nThat also explains why it reacted to that 53c700 even though it wasn't at \nthe beginning of a line.\n\nThat really is a piece of crap.\n\nPeople who think that basic programs like \"patch\" should DWIM stuff like \nthat are incompetent. Yes, I can see how it can be \"convenient\", but \ndammit, whoever added that convenince feature really is a total moron.\n\nAt the very least it should be off by default, and controlled by some flag \n(ie \"patch --dwim\"). As it is, it's on by default, and I don't see any way \nat all to disable it (not in the man-page, and not googling the source \nwith google code-search).\n\nThat's just incredibly broken.\n\nI guess I shouldn't be surprised. The whole \"things should be convenient, \nnot safe\" approach is shown by the default high fuzz-factor too. But at \nleast that one you can disable.\n\nIt's positively microsoftian to make programs blindly be \"convenient\", \nwith no thinking about what that means for security and safety of the end \nresult.\n\nSo I would suggest that in quilt and other systems, you either:\n\n - strip all headers manually\n\n - forget about \"patch\", and use \"git-apply\" instead that does things \n right and doesn't screw up like this (and can do rename diffs etc too).\n\nI guess the second choice generally isn't an option, but dammit, \n\"git-apply\" really is the better program here.\n\n\t\tLinus\n"},{"id":"46320","messageId":"7vhcomuofl.fsf@assigned-by-dhcp.cox.net","threadId":"8818","inReplyTo":"alpine.LFD.0.98.0707021713200.9434@woody.linux-foundation.org","subject":"Re: being nice to patch(1)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-07-03T04:00:14Z","receivedAt":"2007-07-03T04:00:14Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> So I would suggest that in quilt and other systems, you either:\n>\n> - strip all headers manually\n>\n> - forget about \"patch\", and use \"git-apply\" instead that does things \n> right and doesn't screw up like this (and can do rename diffs etc too).\n>\n> I guess the second choice generally isn't an option, but dammit, \n> \"git-apply\" really is the better program here.\n\nWhy not? git-apply works outside of a git repo ;-)\n"},{"id":"46322","messageId":"alpine.LFD.0.98.0707022114000.9434@woody.linux-foundation.org","threadId":"8818","inReplyTo":"7vhcomuofl.fsf@assigned-by-dhcp.cox.net","subject":"Re: being nice to patch(1)","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-07-03T04:14:34Z","receivedAt":"2007-07-03T04:14:34Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 2 Jul 2007, Junio C Hamano wrote:\n> Linus Torvalds writes:\n> \n> > So I would suggest that in quilt and other systems, you either:\n> >\n> > - strip all headers manually\n> >\n> > - forget about \"patch\", and use \"git-apply\" instead that does things \n> > right and doesn't screw up like this (and can do rename diffs etc too).\n> >\n> > I guess the second choice generally isn't an option, but dammit, \n> > \"git-apply\" really is the better program here.\n> \n> Why not? git-apply works outside of a git repo ;-)\n\nI was more thinking that people are not necessarily willing to install git \njust to get the \"git-apply\" program..\n\n\t\tLinus\n"},{"id":"46352","messageId":"Pine.LNX.4.64.0707031303130.4071@racer.site","threadId":"8818","inReplyTo":"alpine.LFD.0.98.0707022114000.9434@woody.linux-foundation.org","subject":"Re: being nice to patch(1)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-07-03T12:04:33Z","receivedAt":"2007-07-03T12:04:33Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 2 Jul 2007, Linus Torvalds wrote:\n\n> On Mon, 2 Jul 2007, Junio C Hamano wrote:\n> > Linus Torvalds writes:\n> > \n> > > So I would suggest that in quilt and other systems, you either:\n> > >\n> > > - strip all headers manually\n> > >\n> > > - forget about \"patch\", and use \"git-apply\" instead that does things \n> > > right and doesn't screw up like this (and can do rename diffs etc too).\n> > >\n> > > I guess the second choice generally isn't an option, but dammit, \n> > > \"git-apply\" really is the better program here.\n> > \n> > Why not? git-apply works outside of a git repo ;-)\n> \n> I was more thinking that people are not necessarily willing to install git \n> just to get the \"git-apply\" program..\n\nBut maybe they would be willing to install git to get that wonderful \ngit-apply program, and that wonderful rename-and-mode-aware git-diff, and \nthe git-merge-file program, all of which can operate outside of a git \nrepository. (Take that, hg!)\n\nCiao,\nDscho\n"},{"id":"46356","messageId":"4d8e3fd30707030521k6cb3129dy9193344e9e1eccf7@mail.gmail.com","threadId":"8818","inReplyTo":"Pine.LNX.4.64.0707031303130.4071@racer.site","subject":"Re: being nice to patch(1)","fromName":"Paolo Ciarrocchi","fromEmail":"paolo.ciarrocchi@gmail.com","sentAt":"2007-07-03T12:21:51Z","receivedAt":"2007-07-03T12:21:51Z","isPatch":false,"sender":{"key":"paolo.ciarrocchi@gmail.com","avatar":null},"body":"On 7/3/07, Johannes Schindelin wrote:\n> Hi,\n> On Mon, 2 Jul 2007, Linus Torvalds wrote:\n> > On Mon, 2 Jul 2007, Junio C Hamano wrote:\n> > > Linus Torvalds writes:\n> > >\n> > > > So I would suggest that in quilt and other systems, you either:\n> > > >\n> > > > - strip all headers manually\n> > > >\n> > > > - forget about \"patch\", and use \"git-apply\" instead that does things\n> > > > right and doesn't screw up like this (and can do rename diffs etc too).\n> > > >\n> > > > I guess the second choice generally isn't an option, but dammit,\n> > > > \"git-apply\" really is the better program here.\n> > >\n> > > Why not? git-apply works outside of a git repo ;-)\n> >\n> > I was more thinking that people are not necessarily willing to install git\n> > just to get the \"git-apply\" program..\n>\n> But maybe they would be willing to install git to get that wonderful\n> git-apply program, and that wonderful rename-and-mode-aware git-diff, and\n> the git-merge-file program, all of which can operate outside of a git\n> repository. (Take that, hg!)\n\nHow about shipping just these commands as a separate package?\nIs that a cray idea?\n\nciao,\n-- \nPaolo\n\"Tutto cio' che merita di essere fatto,merita di essere fatto bene\"\nPhilip Stanhope IV conte di Chesterfield\n"},{"id":"46357","messageId":"Pine.LNX.4.64.0707031334350.4071@racer.site","threadId":"8818","inReplyTo":"4d8e3fd30707030521k6cb3129dy9193344e9e1eccf7@mail.gmail.com","subject":"Re: being nice to patch(1)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-07-03T12:35:44Z","receivedAt":"2007-07-03T12:35:44Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 3 Jul 2007, Paolo Ciarrocchi wrote:\n\n> On 7/3/07, Johannes Schindelin wrote:\n> > Hi,\n> > On Mon, 2 Jul 2007, Linus Torvalds wrote:\n> > > On Mon, 2 Jul 2007, Junio C Hamano wrote:\n> > > > Linus Torvalds writes:\n> > > >\n> > > > > So I would suggest that in quilt and other systems, you either:\n> > > > >\n> > > > > - strip all headers manually\n> > > > >\n> > > > > - forget about \"patch\", and use \"git-apply\" instead that does things\n> > > > > right and doesn't screw up like this (and can do rename diffs etc\n> > too).\n> > > > >\n> > > > > I guess the second choice generally isn't an option, but dammit,\n> > > > > \"git-apply\" really is the better program here.\n> > > >\n> > > > Why not? git-apply works outside of a git repo ;-)\n> > >\n> > > I was more thinking that people are not necessarily willing to install\n> > git\n> > > just to get the \"git-apply\" program..\n> > \n> > But maybe they would be willing to install git to get that wonderful\n> > git-apply program, and that wonderful rename-and-mode-aware git-diff, and\n> > the git-merge-file program, all of which can operate outside of a git\n> > repository. (Take that, hg!)\n> \n> How about shipping just these commands as a separate package?\n> Is that a cray idea?\n\nHeh, all three programs are \"builtins\", which means that you get almost \nthe whole package of git anyway ;-)\n\nCiao,\nDscho\n"},{"id":"46361","messageId":"86y7hxr591.fsf@lola.quinscape.zz","threadId":"8818","inReplyTo":"Pine.LNX.4.64.0707031303130.4071@racer.site","subject":"Re: being nice to patch(1)","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-07-03T13:22:50Z","receivedAt":"2007-07-03T13:22:50Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Johannes Schindelin writes:\n\n> But maybe they would be willing to install git to get that wonderful\n> git-apply program, and that wonderful rename-and-mode-aware\n> git-diff, and the git-merge-file program, all of which can operate\n> outside of a git repository. (Take that, hg!)\n\nAs long as git-diff lists all added files in a second non-git dirtree\nas \"/dev/null\" when doing\ngit-diff --name-status -B -M -C dir1 dir2\nits usefulness is limited.\n\ngit-diff --name-status -B -M -C dir1 dir2\nD\tdir1/auctex-11.84/CHANGES\nD\tdir1/auctex-11.84/COPYING\nD\tdir1/auctex-11.84/ChangeLog\n\n[...]\n\nD\tdir1/auctex-11.84/preview/preview-latex.spec\nD\tdir1/auctex-11.84/preview/prv-emacs.el\nD\tdir1/auctex-11.84/preview/prv-install.el\nD\tdir1/auctex-11.84/tex-site.el.in\nD\tdir1/auctex-11.84/tex-wizard.el\nA\t/dev/null\nA\t/dev/null\nR100\tdir1/auctex-11.84/images/amstex.xpm\tdir2/etc/auctex/images/amstex.xpm\nR100\tdir1/auctex-11.84/images/bibtex.xpm\tdir2/etc/auctex/images/bibtex.xpm\nR100\tdir1/auctex-11.84/images/dropdown.xpm\tdir2/etc/auctex/images/dropdown.xpm\n\n[...]\n\nR100\tdir1/auctex-11.84/images/viewdvi.xpm\tdir2/etc/auctex/images/viewdvi.xpm\nR100\tdir1/auctex-11.84/images/viewpdf.xpm\tdir2/etc/auctex/images/viewpdf.xpm\nR100\tdir1/auctex-11.84/images/viewps.xpm\tdir2/etc/auctex/images/viewps.xpm\nA\t/dev/null\nA\t/dev/null\nA\t/dev/null\nA\t/dev/null\nA\t/dev/null\nA\t/dev/null\n\nand so on.\n\ngit --version\ngit version 1.5.2.2.565.gde09\n\n-- \nDavid Kastrup\n"},{"id":"46362","messageId":"200707031534.47004.agruen@suse.de","threadId":"8818","inReplyTo":"alpine.LFD.0.98.0707021713200.9434@woody.linux-foundation.org","subject":"Re: [Quilt-dev] Re: being nice to patch(1)","fromName":"Andreas Gruenbacher","fromEmail":"agruen@suse.de","sentAt":"2007-07-03T13:34:46Z","receivedAt":"2007-07-03T13:34:46Z","isPatch":false,"sender":{"key":"agruen@suse.de","avatar":null},"body":"On Tuesday 03 July 2007 02:28, Linus Torvalds wrote:\n> So I would suggest that in quilt and other systems, you either:\n>\n> - strip all headers manually\n>\n> - forget about \"patch\", and use \"git-apply\" instead that does things\n> right and doesn't screw up like this (and can do rename diffs etc too).\n>\n> I guess the second choice generally isn't an option, but dammit,\n> \"git-apply\" really is the better program here.\n\nI'm in bit of a conflict with choice one: when applying patches in an \nautomated build process or similar, the likely way to do so is a simple loop \nover the series file. So the less magic when applying patches with quilt, the \nbetter.\n\nTurning off the insane heuristic with patch -u will do well enough I hope. \nQuilt does not use that option by default because it also supports context \ndiffs (some people / projects prefer them), but that can easily be customized \nin .quiltrc:\n\n QUILT_PATCH_OPTS=-u\n\nAndreas\n"},{"id":"46363","messageId":"Pine.LNX.4.64.0707031437560.4071@racer.site","threadId":"8818","inReplyTo":"86y7hxr591.fsf@lola.quinscape.zz","subject":"Re: being nice to patch(1)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-07-03T13:39:32Z","receivedAt":"2007-07-03T13:39:32Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi David,\n\n[please Cc me, since I will be more likely to miss replies if you do not]\n\nOn Tue, 3 Jul 2007, David Kastrup wrote:\n\n> Johannes Schindelin writes:\n> \n> > But maybe they would be willing to install git to get that wonderful \n> > git-apply program, and that wonderful rename-and-mode-aware git-diff, \n> > and the git-merge-file program, all of which can operate outside of a \n> > git repository. (Take that, hg!)\n> \n> As long as git-diff lists all added files in a second non-git dirtree\n> as \"/dev/null\" when doing\n> git-diff --name-status -B -M -C dir1 dir2\n> its usefulness is limited.\n> \n> git-diff --name-status -B -M -C dir1 dir2\n> D\tdir1/auctex-11.84/CHANGES\n> D\tdir1/auctex-11.84/COPYING\n> D\tdir1/auctex-11.84/ChangeLog\n> \n> [...]\n\nYes, directories are a problem. There our DWIMery does not really help. \nBut there is a solution: say\n\n\tgit diff --name-status --no-index -B -M -C dir1 dir2\n\nHth,\nDscho\n"},{"id":"46372","messageId":"86hcolr3sb.fsf@lola.quinscape.zz","threadId":"8818","inReplyTo":"Pine.LNX.4.64.0707031437560.4071@racer.site","subject":"Re: being nice to patch(1)","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-07-03T13:54:28Z","receivedAt":"2007-07-03T13:54:28Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Johannes Schindelin writes:\n\n> Hi David,\n>\n> [please Cc me, since I will be more likely to miss replies if you do not]\n>\n> On Tue, 3 Jul 2007, David Kastrup wrote:\n>\n>> Johannes Schindelin writes:\n>> \n>> > But maybe they would be willing to install git to get that wonderful \n>> > git-apply program, and that wonderful rename-and-mode-aware git-diff, \n>> > and the git-merge-file program, all of which can operate outside of a \n>> > git repository. (Take that, hg!)\n>> \n>> As long as git-diff lists all added files in a second non-git dirtree\n>> as \"/dev/null\" when doing\n>> git-diff --name-status -B -M -C dir1 dir2\n>> its usefulness is limited.\n>> \n>> git-diff --name-status -B -M -C dir1 dir2\n>> D\tdir1/auctex-11.84/CHANGES\n>> D\tdir1/auctex-11.84/COPYING\n>> D\tdir1/auctex-11.84/ChangeLog\n>> \n>> [...]\n>\n> Yes, directories are a problem. There our DWIMery does not really help. \n> But there is a solution: say\n>\n> \tgit diff --name-status --no-index -B -M -C dir1 dir2\n\nIt would help if you actually read what you are replying to. The\nproblem is that added files are listed as \"/dev/null\", and --no-index\ndoes not make a difference here. It actually makes no apparent\ndifference at all when outside of a non-git dirtree. Hardly\nsurprising, since no index file that could be consulted is present in\nthe first place.\n\nThe output still is (editing somewhat more so that it becomes even\nmore obvious):\n\ngit-diff -B -M -C --no-index --name-status dir1 dir2\nD\tdir1/auctex-11.84/CHANGES\n\n[...]\n\nA\t/dev/null\nA\t/dev/null\nR100\tdir1/auctex-11.84/images/amstex.xpm\tdir2/etc/auctex/images/amstex.xpm\n\n[...]\n\n_All_ lines starting in A end with /dev/null.\n\n-- \nDavid Kastrup\n"},{"id":"46376","messageId":"Pine.LNX.4.64.0707031559510.4071@racer.site","threadId":"8818","inReplyTo":"86hcolr3sb.fsf@lola.quinscape.zz","subject":"[PATCH] diff --no-index: fix --name-status with added files","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-07-03T15:01:06Z","receivedAt":"2007-07-03T15:01:06Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"\nWithout this patch, an added file would be reported as /dev/null.\n\nNoticed by David Kastrup.\n\nSigned-off-by: Johannes Schindelin \n---\n\n\tWould be nice, next time, to have a bug report which is not \n\tembedded in a thread.\n\n diff.c | 3 ++-\n t/t4013-diff-various.sh | 2 ++\n t/t4013/diff.diff_--name-status_dir2_dir | 3 +++\n 3 files changed, 7 insertions(+), 1 deletions(-)\n create mode 100644 t/t4013/diff.diff_--name-status_dir2_dir\n\ndiff --git a/diff.c b/diff.c\nindex b6eb72b..1958970 100644\n--- a/diff.c\n+++ b/diff.c\n@@ -2418,7 +2418,8 @@ static void diff_flush_raw(struct diff_filepair *p,\n \t\tprintf(\"%s \",\n \t\t diff_unique_abbrev(p->two->sha1, abbrev));\n \t}\n-\tprintf(\"%s%c%s\", status, inter_name_termination, path_one);\n+\tprintf(\"%s%c%s\", status, inter_name_termination,\n+\t\t\ttwo_paths || p->one->mode ? path_one : path_two);\n \tif (two_paths)\n \t\tprintf(\"%c%s\", inter_name_termination, path_two);\n \tputchar(line_termination);\ndiff --git a/t/t4013-diff-various.sh b/t/t4013-diff-various.sh\nindex b453b42..9eec754 100755\n--- a/t/t4013-diff-various.sh\n+++ b/t/t4013-diff-various.sh\n@@ -17,6 +17,7 @@ test_expect_success setup '\n \texport GIT_AUTHOR_DATE GIT_COMMITTER_DATE &&\n \n \tmkdir dir &&\n+\tmkdir dir2 &&\n \tfor i in 1 2 3; do echo $i; done >file0 &&\n \tfor i in A B; do echo $i; done >dir/sub &&\n \tcat file0 >file2 &&\n@@ -254,6 +255,7 @@ diff --patch-with-stat initial..side\n diff --patch-with-raw initial..side\n diff --patch-with-stat -r initial..side\n diff --patch-with-raw -r initial..side\n+diff --name-status dir2 dir\n EOF\n \n test_done\ndiff --git a/t/t4013/diff.diff_--name-status_dir2_dir b/t/t4013/diff.diff_--name-status_dir2_dir\nnew file mode 100644\nindex 0000000..ef7fdb7\n--- /dev/null\n+++ b/t/t4013/diff.diff_--name-status_dir2_dir\n@@ -0,0 +1,3 @@\n+$ git diff --name-status dir2 dir\n+A\tdir/sub\n+$\n-- \n1.5.3.rc0.2637.g1dd84-dirty\n"},{"id":"46377","messageId":"Pine.LNX.4.64.0707031601100.4071@racer.site","threadId":"8818","inReplyTo":"86hcolr3sb.fsf@lola.quinscape.zz","subject":"Re: being nice to patch(1)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-07-03T15:01:47Z","receivedAt":"2007-07-03T15:01:47Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 3 Jul 2007, David Kastrup wrote:\n\n> It would help if you actually read what you are replying to.\n\nActually, your second explanation helped. Fix posted separately.\n\nCiao,\nDscho\n"},{"id":"46379","messageId":"863b05r0cz.fsf@lola.quinscape.zz","threadId":"8818","inReplyTo":"Pine.LNX.4.64.0707031601100.4071@racer.site","subject":"Re: being nice to patch(1)","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-07-03T15:08:28Z","receivedAt":"2007-07-03T15:08:28Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Johannes Schindelin writes:\n\n> On Tue, 3 Jul 2007, David Kastrup wrote:\n>\n>> It would help if you actually read what you are replying to.\n>\n> Actually, your second explanation helped. Fix posted separately.\n\nThanks.\n\n-- \nDavid Kastrup\n"},{"id":"46381","messageId":"20070703084926.2e834aa5.akpm@linux-foundation.org","threadId":"8818","inReplyTo":"200707031534.47004.agruen@suse.de","subject":"Re: [Quilt-dev] Re: being nice to patch(1)","fromName":"Andrew Morton","fromEmail":"akpm@linux-foundation.org","sentAt":"2007-07-03T15:49:26Z","receivedAt":"2007-07-03T15:49:26Z","isPatch":false,"sender":{"key":"akpm@linux-foundation.org","avatar":null},"body":"On Tue, 3 Jul 2007 15:34:46 +0200 Andreas Gruenbacher wrote:\n\n> On Tuesday 03 July 2007 02:28, Linus Torvalds wrote:\n> > So I would suggest that in quilt and other systems, you either:\n> >\n> > - strip all headers manually\n> >\n> > - forget about \"patch\", and use \"git-apply\" instead that does things\n> > right and doesn't screw up like this (and can do rename diffs etc too).\n> >\n> > I guess the second choice generally isn't an option, but dammit,\n> > \"git-apply\" really is the better program here.\n> \n> I'm in bit of a conflict with choice one: when applying patches in an \n> automated build process or similar, the likely way to do so is a simple loop \n> over the series file. So the less magic when applying patches with quilt, the \n> better.\n> \n> Turning off the insane heuristic with patch -u will do well enough I hope. \n> Quilt does not use that option by default because it also supports context \n> diffs (some people / projects prefer them), but that can easily be customized \n> in .quiltrc:\n> \n> QUILT_PATCH_OPTS=-u\n> \n\nI guess one could try `patch -p1' and if that failed, `patch -p1 -u'.\n\nBut the problem is that patch will get stuck in interactive mode prompting\nfor a filename. I've never actually worked how to make patch(1) just fail\nrather than going interactive, not that I've tried terribly hard. Any\nhints there?\n\nThanks.\n"},{"id":"46383","messageId":"alpine.LFD.0.98.0707030901310.9434@woody.linux-foundation.org","threadId":"8818","inReplyTo":"20070703084926.2e834aa5.akpm@linux-foundation.org","subject":"Re: [Quilt-dev] Re: being nice to patch(1)","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-07-03T16:03:07Z","receivedAt":"2007-07-03T16:03:07Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 3 Jul 2007, Andrew Morton wrote:\n> \n> But the problem is that patch will get stuck in interactive mode prompting\n> for a filename. I've never actually worked how to make patch(1) just fail\n> rather than going interactive, not that I've tried terribly hard. Any\n> hints there?\n\n\"patch -t\" (or \"--batch\") should do it, I suspect.\n\nBut even with \"patch -tu -p1\" you do seem to end up having patch notice \nindented patch fragments (ie things that obviously are *not* part of the \npatch, but some explanation).\n\n\t\tLinus\n"},{"id":"46384","messageId":"200707031803.15633.agruen@suse.de","threadId":"8818","inReplyTo":"20070703084926.2e834aa5.akpm@linux-foundation.org","subject":"Re: [Quilt-dev] Re: being nice to patch(1)","fromName":"Andreas Gruenbacher","fromEmail":"agruen@suse.de","sentAt":"2007-07-03T16:03:15Z","receivedAt":"2007-07-03T16:03:15Z","isPatch":false,"sender":{"key":"agruen@suse.de","avatar":null},"body":"On Tuesday 03 July 2007 17:49, Andrew Morton wrote:\n> I guess one could try `patch -p1' and if that failed, `patch -p1 -u'.\n\nHmm, I'll think about that, thanks.\n\n> But the problem is that patch will get stuck in interactive mode prompting\n> for a filename. I've never actually worked how to make patch(1) just fail\n> rather than going interactive, not that I've tried terribly hard. Any\n> hints there?\n\nPatch -f will turn off those questions.\n\nAndreas\n"},{"id":"46385","messageId":"20070703091539.5b44203d.akpm@linux-foundation.org","threadId":"8818","inReplyTo":"200707031803.15633.agruen@suse.de","subject":"Re: [Quilt-dev] Re: being nice to patch(1)","fromName":"Andrew Morton","fromEmail":"akpm@linux-foundation.org","sentAt":"2007-07-03T16:15:39Z","receivedAt":"2007-07-03T16:15:39Z","isPatch":false,"sender":{"key":"akpm@linux-foundation.org","avatar":null},"body":"On Tue, 3 Jul 2007 18:03:15 +0200 Andreas Gruenbacher wrote:\n\n> On Tuesday 03 July 2007 17:49, Andrew Morton wrote:\n> > I guess one could try `patch -p1' and if that failed, `patch -p1 -u'.\n> \n> Hmm, I'll think about that, thanks.\n> \n> > But the problem is that patch will get stuck in interactive mode prompting\n> > for a filename. I've never actually worked how to make patch(1) just fail\n> > rather than going interactive, not that I've tried terribly hard. Any\n> > hints there?\n> \n> Patch -f will turn off those questions.\n> \n\ndarnit, both `-f' and `-t' work. Sigh. I blame the manpage: too long ;)\n\nIncidentally, the offending patch\n(http://userweb.kernel.org/~akpm/git-scsi-misc.patch) sends patch(1) into\nan infinite loop with `patch -p1 -f' and `patch -p1 -t'. Presumably\nit will do the same when that patch is offered to quilt...\n"},{"id":"46395","messageId":"20070703183947.GE5322@thunk.org","threadId":"8818","inReplyTo":"4d8e3fd30707030521k6cb3129dy9193344e9e1eccf7@mail.gmail.com","subject":"Re: being nice to patch(1)","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2007-07-03T18:39:48Z","receivedAt":"2007-07-03T18:39:48Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Tue, Jul 03, 2007 at 02:21:51PM +0200, Paolo Ciarrocchi wrote:\n> >But maybe they would be willing to install git to get that wonderful\n> >git-apply program, and that wonderful rename-and-mode-aware git-diff, and\n> >the git-merge-file program, all of which can operate outside of a git\n> >repository. (Take that, hg!)\n> \n> How about shipping just these commands as a separate package?\n> Is that a cray idea?\n\nOr people could submit a bug report/feature request/patch to the\npatch(1) maintainer. :-)\n\n\t\t\t\t\t\t- Ted\n"},{"id":"46402","messageId":"alpine.LFD.0.98.0707031159580.9434@woody.linux-foundation.org","threadId":"8818","inReplyTo":"20070703183947.GE5322@thunk.org","subject":"Re: being nice to patch(1)","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-07-03T19:48:31Z","receivedAt":"2007-07-03T19:48:31Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n[ Paul Eggert added to Cc: I'm not sure he actually maintains \"patch\" \n or cares any more, but hopefully he at least knows who does ]\n\nOn Tue, 3 Jul 2007, Theodore Tso wrote:\n> \n> Or people could submit a bug report/feature request/patch to the\n> patch(1) maintainer. :-)\n\nIs there such a thing?\n\nThe latest official version of patch from GNU is 2.5.4 from 1999, I think.\n\nI'm finding references to 2.5.9 in distributions (from 2003), but 2.5.4 is \nthe latest I see on the GNU mirror at kernel.org, and that's also what \nFedora 7 has too, it seems, so the 2.5.9 thing seems to be something \nunofficial or at least not widely known about..\n\nAnyway, I tried to look at the patch sources, but I had to stop. That \nwhole \"intuit_diff_type()\" function is probably designed as an initiation \nrite for any patch programmers, and to make sure that you have to be \nreally serious about wanting to send patches before you can become part of \nthe \"in crowd\". It's \"mental hazing\".\n\nYeah, git-apply sources aren't necessarily a thing of great beauty either, \nbut in comparison to patch, I think it's a work of art. Of course, part of \nit is that it doesn't try to parse 'ed' scripts etc, but a large part of \nit really is that \"patch\" is an old program that has grown over time, and \nnot seen a lot of cleanups, I suspect.\n\nIOW, I tried to see how easy it would be to dismiss the code that \ntakes care of \"indent\", but it wasn't totally obvious. It's set in many \ndifferent places, and the logic for \"skip_this_patch\" is a bit confusing.\n\nAnyway, with Paul Eggert Cc'd, maybe he can help us sort it out.\n\nPaul - the issue here isn't actually with git at all, but the fact that \nAndrew Morton noticed that he cannot apply one of the series of patches he \nhas with \"patch\" (well, with his scripts that are designed _around_ \npatch, to be exact).\n\nThe reason? Part of the patch *description* looked like this:\n\n [SCSI] 53c700: Amiga 4000T NCR53c710 SCSI\n\n New driver for the Amiga 4000T built-in NCR53c710 SCSI controller, using the\n 53c700 SCSI core.\n\nwhere it really *was* indented by four characters (and that's where git \ncomes in: git indents the patch descriptions exactly so that you cannot \n*possibly* confuse the patch itself with the description).\n\nIt turns out that \"patch\" would actually think there is a patch there: the \nline\n\n 53c700 SCSI core.\n\nwas determined to be an ed-script (\"53c700\") _despite_ the fact that it's \nindented.\n\nAndrew was able to fix that particular damage by using \"-u\" and forcing \nanything but unified diffs to be ignored, but that isn't an option for all \nquilt users, since some projects use old-fashioned context diffs or a \nmixture.\n\nBesides, the explanations can certainly contain patch fragments anyway (in \nthe kernel, we put things like example code in them).\n\nAnd it really boils down to a really simple thing: when scripting, you DO \nNOT WANT \"patch\" to make random guesses. And that whole \"indentation\" \nthing by patch is a pure guess, and should simply NOT BE DONE. And there's \nno way to tell patch to not do it.\n\nSo Paul, you're our only hope.\n\nI'm personally trying to tell people not to use \"patch\" at all (this isn't \nthe first time patch has done insane things by default, but it's the first \ntime you cannot even _disable_ the insane behaviour), but Ted has a point: \nregardless of whether people learn to use \"git-apply\" to apply patches, \nthe old \"patch\" binary would be better off just improved.\n\nIn this case, the improvement would be to simply ignore indented patches \n(preferably by default, but at least have the option to do so).\n\n\t\tLinus\n"},{"id":"46406","messageId":"87zm2dxl5l.fsf@penguin.cs.ucla.edu","threadId":"8818","inReplyTo":"alpine.LFD.0.98.0707031159580.9434@woody.linux-foundation.org","subject":"Re: being nice to patch(1)","fromName":"Paul Eggert","fromEmail":"eggert@cs.ucla.edu","sentAt":"2007-07-03T20:55:02Z","receivedAt":"2007-07-03T20:55:02Z","isPatch":false,"sender":{"key":"eggert@cs.ucla.edu","avatar":"https://avatars.githubusercontent.com/u/572024?v=4"},"body":"Linus Torvalds writes:\n\n> Anyway, I tried to look at the patch sources, but I had to stop. That \n> whole \"intuit_diff_type()\" function is probably designed as an initiation \n> rite for any patch programmers, and to make sure that you have to be \n> really serious about wanting to send patches before you can become part of \n> the \"in crowd\". It's \"mental hazing\".\n\nYou should have seen it in the good old days when Larry Wall wrote it.\nIt was at least -- at least! -- 10% worse.\n\n> In this case, the improvement would be to simply ignore indented patches \n> (preferably by default, but at least have the option to do so).\n\nI agree. POSIX has tied our hands to some extent, though, since it\n_requires_ patch to accept indented patches by default. It's too late\nto fix this in the current POSIX go-round, but we can fix it in the\nnext. And in the mean time we can add an option, I suppose defaulting\nto not stripping indentation unless POSIXLY_CORRECT is set. That\nwould be fine with me.\n\nI'll add it to my list of things to do.\n"},{"id":"46410","messageId":"200707032103.l63L3bm18209@f7.net","threadId":"8818","inReplyTo":"200707031803.15633.agruen@suse.de","subject":"Re: Re: being nice to patch(1)","fromName":"Andrew Morton","fromEmail":"akpm@linux-foundation.org","sentAt":"2007-07-03T21:03:37Z","receivedAt":"2007-07-03T21:03:37Z","isPatch":false,"sender":{"key":"akpm@linux-foundation.org","avatar":null},"body":"On Tue, 3 Jul 2007 18:03:15 +0200 Andreas Gruenbacher wrote:\n\n> On Tuesday 03 July 2007 17:49, Andrew Morton wrote:\n> > I guess one could try `patch -p1' and if that failed, `patch -p1 -u'.\n> \n> Hmm, I'll think about that, thanks.\n> \n> > But the problem is that patch will get stuck in interactive mode prompting\n> > for a filename. I've never actually worked how to make patch(1) just fail\n> > rather than going interactive, not that I've tried terribly hard. Any\n> > hints there?\n> \n> Patch -f will turn off those questions.\n> \n\ndarnit, both `-f' and `-t' work. Sigh. I blame the manpage: too long ;)\n\nIncidentally, the offending patch\n(http://userweb.kernel.org/~akpm/git-scsi-misc.patch) sends patch(1) into\nan infinite loop with `patch -p1 -f' and `patch -p1 -t'. Presumably\nit will do the same when that patch is offered to quilt...\n"},{"id":"46411","messageId":"200707032103.l63L3bL18194@f7.net","threadId":"8818","inReplyTo":"200707031534.47004.agruen@suse.de","subject":"Re: Re: being nice to patch(1)","fromName":"Andrew Morton","fromEmail":"akpm@linux-foundation.org","sentAt":"2007-07-03T21:03:37Z","receivedAt":"2007-07-03T21:03:37Z","isPatch":false,"sender":{"key":"akpm@linux-foundation.org","avatar":null},"body":"On Tue, 3 Jul 2007 15:34:46 +0200 Andreas Gruenbacher wrote:\n\n> On Tuesday 03 July 2007 02:28, Linus Torvalds wrote:\n> > So I would suggest that in quilt and other systems, you either:\n> >\n> > - strip all headers manually\n> >\n> > - forget about \"patch\", and use \"git-apply\" instead that does things\n> > right and doesn't screw up like this (and can do rename diffs etc too).\n> >\n> > I guess the second choice generally isn't an option, but dammit,\n> > \"git-apply\" really is the better program here.\n> \n> I'm in bit of a conflict with choice one: when applying patches in an \n> automated build process or similar, the likely way to do so is a simple loop \n> over the series file. So the less magic when applying patches with quilt, the \n> better.\n> \n> Turning off the insane heuristic with patch -u will do well enough I hope. \n> Quilt does not use that option by default because it also supports context \n> diffs (some people / projects prefer them), but that can easily be customized \n> in .quiltrc:\n> \n> QUILT_PATCH_OPTS=-u\n> \n\nI guess one could try `patch -p1' and if that failed, `patch -p1 -u'.\n\nBut the problem is that patch will get stuck in interactive mode prompting\nfor a filename. I've never actually worked how to make patch(1) just fail\nrather than going interactive, not that I've tried terribly hard. Any\nhints there?\n\nThanks.\n"},{"id":"46407","messageId":"alpine.LFD.0.98.0707031422201.9434@woody.linux-foundation.org","threadId":"8818","inReplyTo":"87zm2dxl5l.fsf@penguin.cs.ucla.edu","subject":"Re: being nice to patch(1)","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-07-03T21:30:46Z","receivedAt":"2007-07-03T21:30:46Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 3 Jul 2007, Paul Eggert wrote:\n>\n> Linus Torvalds writes:\n> \n> > Anyway, I tried to look at the patch sources, but I had to stop. That \n> > whole \"intuit_diff_type()\" function is probably designed as an initiation \n> > rite for any patch programmers, and to make sure that you have to be \n> > really serious about wanting to send patches before you can become part of \n> > the \"in crowd\". It's \"mental hazing\".\n> \n> You should have seen it in the good old days when Larry Wall wrote it.\n> It was at least -- at least! -- 10% worse.\n\nHeh.\n\nAnyway, I figured out a sane way to do this - I had been thinking about it \nall wrong. Instead of worrying about all the places that change (and look \nat) \"p_indent\" - which is the real variable - I just made it not calculate \n\"indent\" in the first place.\n\nThat makes it catch it all in one place, and then quite naturally ignore \nany indented hunks because it won't recognize them as patches any more. At \nleast I _think_ so, from just reading the source code.\n\nSo a patch like the following may or may not work. It compiles, but quite \nfrankly, while it makes sense and worked for the single test-case I \nbothered with, somebody should double-check the logic.\n\n> > In this case, the improvement would be to simply ignore indented patches \n> > (preferably by default, but at least have the option to do so).\n> \n> I agree. POSIX has tied our hands to some extent, though, since it\n> _requires_ patch to accept indented patches by default. It's too late\n> to fix this in the current POSIX go-round, but we can fix it in the\n> next. And in the mean time we can add an option, I suppose defaulting\n> to not stripping indentation unless POSIXLY_CORRECT is set. That\n> would be fine with me.\n> \n> I'll add it to my list of things to do.\n\nOk, so this doesn't do the POSIXLY_CORRECT thing, and you may not agree \nwith the flag name either (\"--strip-indent\" is a lot of characters to \nwrite, but I thought it was so esoteric that I think it's ok. I never even \nrealized \"patch\" would ever do something as strange as that, and I'm \nhoping a lot of other people didn't realize either, so that changing this \nisn't going to matter, and very few people would hopefully ever need to \nuse the \"--strip-indent\" flag).\n\nBut maybe you can use this patch as a starting point, at least.\n\n(And if you wonder why I put the \"if (!strip_indentation)\" thing inside \nthe loop, even though it doesn't ever change in the loop: it generated a \nsmaller patch, and I didn't want to re-indent that code and make it even \nworse. So the logic is kind of stupid, but whatever..)\n\n\t\tLinus\n\n---\ndiff --git a/common.h b/common.h\nindex c7fc5c2..45fecdc 100644\n--- a/common.h\n+++ b/common.h\n@@ -174,6 +174,7 @@ XTERN bool canonicalize;\n XTERN int patch_get;\n XTERN bool set_time;\n XTERN bool set_utc;\n+XTERN bool strip_indentation;\n \n enum diff\n {\ndiff --git a/patch.c b/patch.c\nindex 9e04daf..6e25d2a 100644\n--- a/patch.c\n+++ b/patch.c\n@@ -522,6 +522,7 @@ static struct option const longopts[] =\n {\"no-backup-if-mismatch\", no_argument, NULL, CHAR_MAX + 6},\n {\"posix\", no_argument, NULL, CHAR_MAX + 7},\n {\"quoting-style\", required_argument, NULL, CHAR_MAX + 8},\n+ {\"strip-indent\", no_argument, NULL, CHAR_MAX + 9},\n {NULL, no_argument, NULL, 0}\n };\n \n@@ -580,6 +581,7 @@ static char const *const option_help[] =\n \" --verbose Output extra information about the work being done.\",\n \" --dry-run Do not actually change any files; just print what would happen.\",\n \" --posix Conform to the POSIX standard.\",\n+\" --strip-indent handle indented patches.\",\n \"\",\n \" -d DIR --directory=DIR Change the working directory to DIR first.\",\n #if HAVE_SETMODE_DOS\n@@ -779,6 +781,9 @@ get_some_switches (void)\n \t\t\t\t (enum quoting_style) i);\n \t\t}\n \t\tbreak;\n+\t case CHAR_MAX + 9: /* --strip-indent */\n+\t\tstrip_indentation = true;\n+\t\tbreak;\n \t default:\n \t\tusage (stderr, 2);\n \t}\ndiff --git a/pch.c b/pch.c\nindex d98af86..fcb08c5 100644\n--- a/pch.c\n+++ b/pch.c\n@@ -345,6 +345,8 @@ intuit_diff_type (void)\n \t}\n \tstrip_trailing_cr = 2 <= chars_read && buf[chars_read - 2] == '\\r';\n \tfor (s = buf; *s == ' ' || *s == '\\t' || *s == 'X'; s++) {\n+\t if (!strip_indentation)\n+\t\tbreak;\n \t if (*s == '\\t')\n \t\tindent = (indent + 8) & ~7;\n \t else\n"},{"id":"46408","messageId":"alpine.LFD.0.98.0707031432202.9434@woody.linux-foundation.org","threadId":"8818","inReplyTo":"alpine.LFD.0.98.0707031422201.9434@woody.linux-foundation.org","subject":"Re: being nice to patch(1)","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-07-03T21:35:54Z","receivedAt":"2007-07-03T21:35:54Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 3 Jul 2007, Linus Torvalds wrote:\n> \n> But maybe you can use this patch as a starting point, at least.\n\nOh, Paul - I forgot to mention, and since it wasn't necessarily clear from \nthe patch..\n\nI used the patch-2.5.9 sources as a base for this. I don't know how \nofficial that source base is, I picked it up from a Debian package as the \n\"original tar-ball\": patch_2.5.9.orig.tar.gz\n\nI suspect it applies to just about any version of patch with no \nmodifications, but just to clarify what the base was. Judging by the \nChangeLog, you're the one who has been doing the later 2.5.x releases even \nthough the last version on the GNU sites is 2.5.4.\n\nConfusing.\n\n\t\t\tLinus\n"},{"id":"46618","messageId":"86644xd7wr.fsf@lola.quinscape.zz","threadId":"8818","inReplyTo":"Pine.LNX.4.64.0707031303130.4071@racer.site","subject":"Re: being nice to patch(1)","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-07-06T12:38:12Z","receivedAt":"2007-07-06T12:38:12Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Johannes Schindelin writes:\n\n>> > >\n>> > > I guess the second choice generally isn't an option, but dammit, \n>> > > \"git-apply\" really is the better program here.\n>> > \n>> > Why not? git-apply works outside of a git repo ;-)\n>> \n>> I was more thinking that people are not necessarily willing to install git \n>> just to get the \"git-apply\" program..\n>\n> But maybe they would be willing to install git to get that wonderful\n> git-apply program, and that wonderful rename-and-mode-aware\n> git-diff, and the git-merge-file program, all of which can operate\n> outside of a git repository. (Take that, hg!)\n\nWell, hmph! I just rewrote my git-diff-using script to not check\nstuff into a throw-away git repository, and guess what: with real-life\nuse cases (diffing trees of about 500MB size), git-diff runs out of\nmemory (the machine probably has something like 1.5GB of virtual memory\nsize) when operating outside of a git repository.\n\nSo the usefulness still seems limited, even now that the output format\nof --name-status has been fixed.\n\nAny idea whether this is a bug, sloppy programming, or an inherent\nrestriction/necessity?\n\nAlso an idea which of the following scenarios would be best for\ncatching all of moves/renames/deletes/adds? Note: any repository is\nstrictly throw-away.\n\nExperiments are somewhat time-consuming, so every hunch helps.\n\na) diff directories outside of git (works, but fatal memory footprint\n for large cases)\nb) diff index against work directory\nc) diff revision against work directory\nd) diff revision against index\ne) diff revision against revision (works, but high disk footprint and\n likely slower than alternatives)\n\nThanks,\n\n-- \nDavid Kastrup\n"},{"id":"46636","messageId":"864pkha76p.fsf_-_@lola.quinscape.zz","threadId":"8818","inReplyTo":"86644xd7wr.fsf@lola.quinscape.zz","subject":"git-diff memory/speed/disk impacts (was: being nice to patch(1))","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-07-06T15:22:06Z","receivedAt":"2007-07-06T15:22:06Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"\nSome more experiments:\n\nDavid Kastrup writes:\n\n> Johannes Schindelin writes:\n>\n>>> > >\n>>> > > I guess the second choice generally isn't an option, but dammit, \n>>> > > \"git-apply\" really is the better program here.\n>>> > \n>>> > Why not? git-apply works outside of a git repo ;-)\n>>> \n>>> I was more thinking that people are not necessarily willing to install git \n>>> just to get the \"git-apply\" program..\n>>\n>> But maybe they would be willing to install git to get that wonderful\n>> git-apply program, and that wonderful rename-and-mode-aware\n>> git-diff, and the git-merge-file program, all of which can operate\n>> outside of a git repository. (Take that, hg!)\n>\n> Well, hmph! I just rewrote my git-diff-using script to not check\n> stuff into a throw-away git repository, and guess what: with real-life\n> use cases (diffing trees of about 500MB size), git-diff runs out of\n> memory (the machine probably has something like 1.5GB of virtual memory\n> size) when operating outside of a git repository.\n>\n> So the usefulness still seems limited, even now that the output format\n> of --name-status has been fixed.\n>\n> Any idea whether this is a bug, sloppy programming, or an inherent\n> restriction/necessity?\n>\n> Also an idea which of the following scenarios would be best for\n> catching all of moves/renames/deletes/adds? Note: any repository is\n> strictly throw-away.\n>\n> Experiments are somewhat time-consuming, so every hunch helps.\n>\n> a) diff directories outside of git (works, but fatal memory footprint\n> for large cases)\n> b) diff index against work directory\nfatal memory footprint\n> c) diff revision against work directory\nfatal memory footprint\n> d) diff revision against index\ndoes not detect copies/renames\n> e) diff revision against revision (works, but high disk footprint and\n> likely slower than alternatives)\n\nSo it seems like option e) is the only feasible option. In the total\nnumbers, git-add is by far the slowest operation, followed by\ngit-commit. git-diff on revisions is quite fast and with moderate\nmemory footprint.\n\nCommitting itself does not seem to add much disk space: adding into\nthe index seems to be the main disk space allocation.\n\nSo while the behavior of d) appears puzzling, doing another commit\nbefore the diff is cheap, so the motivation for asking people to find\nout the problems with d) is low for me.\n\nSomewhat dissatisfactory that rewriting my script for using the\nrepository-less variant of git-diff fails for seriously large use\ncases due to out-of-memory conditions.\n\nI suppose that's life.\n\n-- \nDavid Kastrup\n"},{"id":"46651","messageId":"alpine.LFD.0.98.0707061102280.9434@woody.linux-foundation.org","threadId":"8818","inReplyTo":"86644xd7wr.fsf@lola.quinscape.zz","subject":"Re: being nice to patch(1)","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-07-06T18:08:10Z","receivedAt":"2007-07-06T18:08:10Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 6 Jul 2007, David Kastrup wrote:\n> \n> Well, hmph! I just rewrote my git-diff-using script to not check\n> stuff into a throw-away git repository, and guess what: with real-life\n> use cases (diffing trees of about 500MB size), git-diff runs out of\n> memory (the machine probably has something like 1.5GB of virtual memory\n> size) when operating outside of a git repository.\n\nOk, that's probably some huge memory leak that just doesn't show up with \nany normal git operations, likely simply because all the normal git \noperations will have thrown out the case of \"identical files\" without ever \neven looking at the file.\n\nI'd guess that when using the diff logic on outside files, we'll read them \nall in, compare them, and keep them all in memory even though they are \nidentical.\n\nGenerally, though, \"git diff\" has a much higher memory footprint than any \nnormal file-by-file recursive diff, exactly because of the rename logic. \nAn external \"diff\" won't ever have any reason to keep more than two files \nin memory at a time, but because git diff does rename and copy detection, \nit wants to keep the file data in memory over much longer times.\n\nBut I bet there is some stupid bug where we just make it much much worse \nfor the \"no git tree/index\" case, and keep the whole tree in memory or \nsomething.\n\n(The same is true of \"git apply\", btw, for a different reason: because \ngit-apply will refuse to write out partial results in case some later \npatch fails, git-apply will keep the whole result in memory until the very \nend, and then do the write-out in one go. Again, that obviously means \nthat it will potentially use a lot more memory than the \"one patch at a \ntime\" approach that regular \"patch\" does)\n\n\t\t\tLinus\n"}]}