{"thread":{"id":"24823","subject":"[PATCH 0/2] git-merge: ignore space support","startedAt":"2010-08-22T05:43:21Z","lastAt":"2010-08-23T20:34:13Z","messageCount":3,"participants":["Justin Frankel","Jonathan Nieder"],"isPatch":true,"patchVersion":1,"patchTotal":2},"messages":[{"id":"148691","messageId":"20100822054321.GA64856@ns1.cockos.com","threadId":"24823","inReplyTo":null,"subject":"[PATCH 0/2] git-merge: ignore space support","fromName":"Justin Frankel","fromEmail":"justin@cockos.com","sentAt":"2010-08-22T05:43:21Z","receivedAt":"2010-08-22T05:43:21Z","isPatch":true,"sender":{"key":"justin@cockos.com","avatar":"https://avatars.githubusercontent.com/u/5803984?v=4"},"body":"Hello,\n\n(Sorry if this is a duplicate, I'm thinking my MIME encoding was causing this \nto get filtered).\n\nI've added  support for merging with ignoring line endings (specifically \n--ignore-space-at-eol) when using recursive merging.  I've added this as a \nstrategy-option, so that you can do:\n\n   git merge --strategy-option=ignore-space-at-eol <branch>\n\nand\n\n   git rebase --strategy-option=ignore-space-at-eol <branch>\n\nThe only option I needed was ignore-space-at-eol, however it made some sense (to \nme at least) to include the other xdiff options  (ignore-space-change, \nignore-all-space, patient).\n\nI researched why this wasn't supported already, and only found some vague \nreferences to why it shouldn't be in there -- if so, I would like to hear that \nexplanation (it does seem to me like it should be a good thing to support, even \nif you strongly discourage use of it -- it would have saved me many hours \nyesterday had it been available, but that of course isn't git's fault, but \nXcode's. ). \n\nWhich branches should we derive from for things like this? The first patch is \nfor master, the second for next (there were enough changes in ll-merge that \nthe implementations are a bit different).\n\nThank you for your time, and I'm very happy to be using Git! It is wonderful.\n\nCheers,\n\nJustin\n"},{"id":"148772","messageId":"20100823193300.GA2120@burratino","threadId":"24823","inReplyTo":"20100822054321.GA64856@ns1.cockos.com","subject":"Re: [PATCH 0/2] git-merge: ignore space support","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-08-23T19:33:00Z","receivedAt":"2010-08-23T19:33:00Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"(+cc: Eyvind Bernhardsen, resident scholar on LF/CRLF conflicts)\n\nHi!\n\nJustin Frankel wrote:\n\n> I've added  support for merging with ignoring line endings (specifically \n> --ignore-space-at-eol) when using recursive merging.  I've added this as a \n> strategy-option, so that you can do:\n> \n>    git merge --strategy-option=ignore-space-at-eol <branch>\n> \n> and\n> \n>    git rebase --strategy-option=ignore-space-at-eol <branch>\n> \n> The only option I needed was ignore-space-at-eol, however it made some sense (to \n> me at least) to include the other xdiff options  (ignore-space-change, \n> ignore-all-space, patient).\n\nInteresting.  The idea seems sane, provided it copes with edge cases\nwell (haven't checked the code yet).\n\nI have even wished for a \"merge -Xpatience\" from time to time.\n\n> Which branches should we derive from for things like this? The first patch is \n> for master, the second for next (there were enough changes in ll-merge that \n> the implementations are a bit different).\n\nSee Documentation/SubmittingPatches, section labelled \"Decide what to\nbase your work on\".\n\nGenerally the rule is to develop features against \"master\", or on top\nof a relevant topic branch from \"next\" or \"pu\" if your implementation\nrequires features from it (or if it is likely to create heavy\nconflicts).\n\nIf the patches seem sane, is it all right if we forge your sign-off?  (See\nDocumentation/SubmittingPatches for what this means.)\n\nSince the threading does not seem to have worked correctly, here are\nthe patches, for reference.\n\nfor master: http://thread.gmane.org/gmane.comp.version-control.git/154166\nfor next: http://thread.gmane.org/gmane.comp.version-control.git/154167\n\nThanks,\nJonathan\n"},{"id":"148782","messageId":"4C72DB45.1080902@cockos.com","threadId":"24823","inReplyTo":"20100823193300.GA2120@burratino","subject":"Re: [PATCH 0/2] git-merge: ignore space support","fromName":"Justin Frankel","fromEmail":"justin@cockos.com","sentAt":"2010-08-23T20:34:13Z","receivedAt":"2010-08-23T20:34:13Z","isPatch":true,"sender":{"key":"justin@cockos.com","avatar":"https://avatars.githubusercontent.com/u/5803984?v=4"},"body":"Jonathan Nieder wrote:\n> (+cc: Eyvind Bernhardsen, resident scholar on LF/CRLF conflicts)\n>\n> Hi!\n>\n> Justin Frankel wrote:\n>\n>   \n>> I've added  support for merging with ignoring line endings (specifically \n>> --ignore-space-at-eol) when using recursive merging.  I've added this as a \n>> strategy-option, so that you can do:\n>>\n>>    git merge --strategy-option=ignore-space-at-eol <branch>\n>>\n>> and\n>>\n>>    git rebase --strategy-option=ignore-space-at-eol <branch>\n>>\n>> The only option I needed was ignore-space-at-eol, however it made some sense (to \n>> me at least) to include the other xdiff options  (ignore-space-change, \n>> ignore-all-space, patient).\n>>     \n>\n> Interesting.  The idea seems sane, provided it copes with edge cases\n> well (haven't checked the code yet).\n>\n> I have even wished for a \"merge -Xpatience\" from time to time.\n>\n>   \nI've mostly used it for dealing with a bunch of mixed-line-ending files \n(Xcode 3.1 has a nasty habit of converting all CRLFs to LFs, and VC6 \ntends to just use CRLFs for inserted lines). For my tests it has worked \nvery well. I'm not completely sure of the implications -- if you start \nmerging code with various line endings, you probably end up with an \nannoying mix of them, forcing you to use -Xignore-space-at-eol for all \nfuture merges on those files.. So it is probably worth discouraging use \nof this, but is also a lifesaver if you have existing code that is messy.\n>> Which branches should we derive from for things like this? The first patch is \n>> for master, the second for next (there were enough changes in ll-merge that \n>> the implementations are a bit different).\n>>     \n>\n> See Documentation/SubmittingPatches, section labelled \"Decide what to\n> base your work on\".\n>\n> Generally the rule is to develop features against \"master\", or on top\n> of a relevant topic branch from \"next\" or \"pu\" if your implementation\n> requires features from it (or if it is likely to create heavy\n> conflicts).\n>\n> If the patches seem sane, is it all right if we forge your sign-off?  (See\n> Documentation/SubmittingPatches for what this means.)\n>\n> Since the threading does not seem to have worked correctly, here are\n> the patches, for reference.\n>\n> for master: http://thread.gmane.org/gmane.comp.version-control.git/154166\n> for next: http://thread.gmane.org/gmane.comp.version-control.git/154167\n>\n>   \nThank you for pointing to me to this file (I had looked a bunch of \nplaces on the web but didn't think to look at the Documentation, shame \non me). If you like I can clean up some stuff I did wrong (including the \ncommit messages, as well as it appears some of my lines have indentation \nwith spaces instead of tabs), and sign-off and resend.\n\nThank you again for the explanation and help, I very much appreciate \nyour time.\n\n-Justin\n"}]}