{"thread":{"id":"28273","subject":"Rebase & Trailing Whitespace","startedAt":"2011-08-31T23:55:03Z","lastAt":"2011-09-09T19:38:42Z","messageCount":8,"participants":["Hilco Wijbenga","Jeff King","Philip Oakley","Michael J Gruber","Clemens Buchacher"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"174649","messageId":"CAE1pOi0rY4kRR4rvEdFhzzTgfhUczHMX=H5_9+o5aHnv4vTadw@mail.gmail.com","threadId":"28273","inReplyTo":null,"subject":"Rebase & Trailing Whitespace","fromName":"Hilco Wijbenga","fromEmail":"hilco.wijbenga@gmail.com","sentAt":"2011-08-31T23:55:03Z","receivedAt":"2011-08-31T23:55:03Z","isPatch":false,"sender":{"key":"hilco.wijbenga@gmail.com","avatar":null},"body":"Hi all,\n\nPlease have a look at the output below.\n\nhilco@centaur ~/workspaces/project-next project-next (next $)$ git rebase master\nFirst, rewinding head to replay your work on top of it...\nApplying: ...\nApplying: ...\nUsing index info to reconstruct a base tree...\nFalling back to patching base and 3-way merge...\nNo changes -- Patch already applied.\nApplying: ...\n:\nApplying: Use static WAR for SWF files and assets.\nUsing index info to reconstruct a base tree...\n<stdin>:721810: trailing whitespace.\nCanadian word list.\n<stdin>:721859: trailing whitespace.\nSFX N   y     ication    y\n<stdin>:721860: trailing whitespace.\nSFX N   0     en         [^ey]\n<stdin>:721869: trailing whitespace.\nSFX H   0     th         [^y]\n<stdin>:721876: trailing whitespace.\nSFX G   0     ing        [^e]\nwarning: squelched 1067 whitespace errors\nwarning: 1072 lines add whitespace errors.\nFalling back to patching base and 3-way merge...\n:\nFailed to merge in the changes.\nPatch failed at 0008 Use static WAR for SWF files and assets.\n\nNote the trailing whitespace warnings. How do I find out which file(s)\ngenerated these warnings? Would it be possible to add the file name\ncausing the warnings to be output? By default? (Using --verbose\ndoesn't seem to make any difference where the whitespace warnings are\nconcerned.)\n\nFurthermore, why didn't I get these or similar warnings when I\ncommitted/pushed that particular commit (\"Use static WAR for SWF files\nand assets.\")? I did just find \"[core] whitespace = trailing-space\"\nwhich I will add to my .gitconfig, I suppose. So I guess what I really\nmean to ask is, why do rebase (and merge?) behave differently from\ncommit?\n\nCheers,\nHilco\n"},{"id":"174654","messageId":"20110901023127.GB31838@sigill.intra.peff.net","threadId":"28273","inReplyTo":"CAE1pOi0rY4kRR4rvEdFhzzTgfhUczHMX=H5_9+o5aHnv4vTadw@mail.gmail.com","subject":"Re: Rebase & Trailing Whitespace","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-09-01T02:31:27Z","receivedAt":"2011-09-01T02:31:27Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Aug 31, 2011 at 04:55:03PM -0700, Hilco Wijbenga wrote:\n\n> hilco@centaur ~/workspaces/project-next project-next (next $)$ git rebase master\n> [...]\n> <stdin>:721810: trailing whitespace.\n> [...]\n> Note the trailing whitespace warnings. How do I find out which file(s)\n> generated these warnings? Would it be possible to add the file name\n> causing the warnings to be output? By default? (Using --verbose\n> doesn't seem to make any difference where the whitespace warnings are\n> concerned.)\n\nYou can see any whitespace warnings in your repository (and in which\ncommit they were introduced) by doing something like:\n\n  git log --oneline --check\n\nThe \"--check\" option is just another diff output format, so you use it\nwith \"log\" or \"diff\". For example, if you want to see just whitespace\nproblems that still exist in your current tree, you can diff against the\nempty tree with --check, like:\n\n  git diff --check 4b825dc642cb6eb9a060e54bf8d69288fbee4904\n\nwhere \"4b825dc...\" is the well-known sha1 of an empty tree[1].\n\n> Furthermore, why didn't I get these or similar warnings when I\n> committed/pushed that particular commit (\"Use static WAR for SWF files\n> and assets.\")? I did just find \"[core] whitespace = trailing-space\"\n> which I will add to my .gitconfig, I suppose. So I guess what I really\n> mean to ask is, why do rebase (and merge?) behave differently from\n> commit?\n\nBecause these warnings are only triggered by default when applying\npatches. And the idea of rebase is to apply patches from one place to\nanother. I thought we squelched whitespace warnings for rebase these\ndays (since they are somewhat pointless; you are moving around your own\ncommits, not applying commits from some other contributor), but maybe I\nam misremembering. Or maybe you have an older version of git. Which\nversion are you using?\n\nIf you want to enforce whitespace checks during commit or push, you can\ndo so with a hook. The sample \"pre-commit\" hook, for example, uses \"diff\n--check\" for just this purpose. See \"git help hooks\" for more\ninformation.\n\n-Peff\n\n[1] If you don't remember the empty tree sha1, you can always derive it\n    with:\n\n        git hash-object -t tree /dev/null\n"},{"id":"174707","messageId":"29267EE41F9343E68AAAE2C33AA40E1A@PhilipOakley","threadId":"28273","inReplyTo":"20110901023127.GB31838@sigill.intra.peff.net","subject":"Re: Rebase & Trailing Whitespace","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2011-09-01T21:00:38Z","receivedAt":"2011-09-01T21:00:38Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Jeff King\" <peff@peff.net>\n> On Wed, Aug 31, 2011 at 04:55:03PM -0700, Hilco Wijbenga wrote:\n\n> problems that still exist in your current tree, you can diff against the\n> empty tree with --check, like:\n>\n>  git diff --check 4b825dc642cb6eb9a060e54bf8d69288fbee4904\n>\n> where \"4b825dc...\" is the well-known sha1 of an empty tree[1].\n>\n\n> [1] If you don't remember the empty tree sha1, you can always derive it\n>    with:\n>\n>        git hash-object -t tree /dev/null\n>\n\nI've added this tip to the https://git.wiki.kernel.org/index.php/Aliases \npage\n\nPhilip \n"},{"id":"174709","messageId":"20110901212618.GB16308@sigill.intra.peff.net","threadId":"28273","inReplyTo":"29267EE41F9343E68AAAE2C33AA40E1A@PhilipOakley","subject":"Re: Rebase & Trailing Whitespace","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-09-01T21:26:18Z","receivedAt":"2011-09-01T21:26:18Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Sep 01, 2011 at 10:00:38PM +0100, Philip Oakley wrote:\n\n> >[1] If you don't remember the empty tree sha1, you can always derive it\n> >   with:\n> >\n> >       git hash-object -t tree /dev/null\n> >\n> \n> I've added this tip to the\n> https://git.wiki.kernel.org/index.php/Aliases page\n\nThanks. By itself, I think many readers would ask \"why would I want the\nempty tree, so I threw in a few examples of use on the wiki, too.\n\n-Peff\n"},{"id":"174736","messageId":"4E6086AA.40806@drmicha.warpmail.net","threadId":"28273","inReplyTo":"20110901212618.GB16308@sigill.intra.peff.net","subject":"Re: Rebase & Trailing Whitespace","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-09-02T07:32:58Z","receivedAt":"2011-09-02T07:32:58Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Jeff King venit, vidit, dixit 01.09.2011 23:26:\n> On Thu, Sep 01, 2011 at 10:00:38PM +0100, Philip Oakley wrote:\n> \n>>> [1] If you don't remember the empty tree sha1, you can always derive it\n>>>   with:\n>>>\n>>>       git hash-object -t tree /dev/null\n>>>\n>>\n>> I've added this tip to the\n>> https://git.wiki.kernel.org/index.php/Aliases page\n> \n> Thanks. By itself, I think many readers would ask \"why would I want the\n> empty tree, so I threw in a few examples of use on the wiki, too.\n\nUgh. I mean: Thanks for the wiki entries, they're nice, but have you\nchecked git.git for whitespace errors? Time for another war on\nwhitespace? Many false positives, of course, but also true positives.\n\nMichael\n"},{"id":"174738","messageId":"20110902082851.GA17703@sigill.intra.peff.net","threadId":"28273","inReplyTo":"4E6086AA.40806@drmicha.warpmail.net","subject":"Re: Rebase & Trailing Whitespace","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-09-02T08:28:51Z","receivedAt":"2011-09-02T08:28:51Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Sep 02, 2011 at 09:32:58AM +0200, Michael J Gruber wrote:\n\n> > Thanks. By itself, I think many readers would ask \"why would I want the\n> > empty tree, so I threw in a few examples of use on the wiki, too.\n> \n> Ugh. I mean: Thanks for the wiki entries, they're nice, but have you\n> checked git.git for whitespace errors? Time for another war on\n> whitespace? Many false positives, of course, but also true positives.\n\nYeah, there are a lot. Because of the potential disruption to patches in\nprogress, though, we tend not to do big bulk updates of style changes.\nBut it may be worth using the\n\n  rm foo.c\n  git diff -R | git apply --whitespace=fix\n\ntrick if you are going to be working on foo.c. And if there are a lot,\nyou can \"add -p\" whatever fixes are appropriate for the area you're\nworking in.\n\n-Peff\n"},{"id":"174797","messageId":"20110903201832.GB8362@ecki","threadId":"28273","inReplyTo":"20110902082851.GA17703@sigill.intra.peff.net","subject":"Re: Rebase & Trailing Whitespace","fromName":"Clemens Buchacher","fromEmail":"drizzd@aon.at","sentAt":"2011-09-03T20:18:32Z","receivedAt":"2011-09-03T20:18:32Z","isPatch":false,"sender":{"key":"drizzd@gmx.net","avatar":"https://avatars.githubusercontent.com/u/59082?v=4"},"body":"On Fri, Sep 02, 2011 at 04:28:51AM -0400, Jeff King wrote:\n> \n> Yeah, there are a lot. Because of the potential disruption to patches in\n> progress, though, we tend not to do big bulk updates of style changes.\n> But it may be worth using the\n> \n>   rm foo.c\n>   git diff -R | git apply --whitespace=fix\n\nI am looking at the output of:\n\n git diff --check 4b825 -- $(git ls-files '*.[ch]'|grep -v ^compat)\n\nMost of those are false positives from multiline function argument\nlists, which are aligned with the first line. So the above command\nwould break more than it would fix.\n\nI don't care either way, but for future reference: Do we or do we\nnot want indentation with spaces in this case?\n\nClemens\n"},{"id":"175234","messageId":"20110909193842.GA31109@sigill.intra.peff.net","threadId":"28273","inReplyTo":"20110903201832.GB8362@ecki","subject":"Re: Rebase & Trailing Whitespace","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-09-09T19:38:42Z","receivedAt":"2011-09-09T19:38:42Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Sep 03, 2011 at 10:18:32PM +0200, Clemens Buchacher wrote:\n\n> I am looking at the output of:\n> \n>  git diff --check 4b825 -- $(git ls-files '*.[ch]'|grep -v ^compat)\n> \n> Most of those are false positives from multiline function argument\n> lists, which are aligned with the first line. So the above command\n> would break more than it would fix.\n> \n> I don't care either way, but for future reference: Do we or do we\n> not want indentation with spaces in this case?\n\nI thought our policy was that a tab is 8 spaces, and that indentations\nof size N should be floor(N/8) tabs and (N%8) spaces. I know other\nprojects disagree (e.g., they want tabs for structural indentation and\nspaces for all other alignment), but that seems to be the general use in\ngit.\n\n-Peff\n"}]}