{"thread":{"id":"37057","subject":"Idea, Transparent commits, easier \"code style\" commits","startedAt":"2014-07-04T13:12:05Z","lastAt":"2014-07-06T13:37:00Z","messageCount":4,"participants":["Andrius Bentkus","Stefan Beller","Javier Domingo Cansino"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"245405","messageId":"CAAwotL2a=2syXMCjPsNB9Tzaw1Rrr4UqDyLX9+JYDE-izpJnLg@mail.gmail.com","threadId":"37057","inReplyTo":null,"subject":"Idea, Transparent commits, easier \"code style\" commits","fromName":"Andrius Bentkus","fromEmail":"andrius.bentkus@gmail.com","sentAt":"2014-07-04T13:12:05Z","receivedAt":"2014-07-04T13:12:05Z","isPatch":false,"sender":{"key":"andrius.bentkus@gmail.com","avatar":null},"body":"I have worked on projects which only after a while (a year or so)\nestablished a consistent code style.\nAfter the consensus was established there was still some code left\nwhich did not fit the newly established standard.\nNow the problem is, if I create a new patch to actually fix it, it\nwill pollute the blame history.\nAnd most of the projects just reject these kind of patches because of this.\n\nImagine that you would have a type conversion \"(int)value\" and wanted\nit to change to \"(int) value\".\nThe patch will have hundreds of occurrences of this one line changes\nand will make the git blame look like swiss cheese.\nIt doesn't add much information to the line (you'd rather have\ntechnical explanations in the commit) and actually hides all the\noriginal comments of the line.\n\nSo you kinda want to have that style fix patch because inconsistent\ncode style just triggers your OCD, but you can't do anything about it\nbecause it doesn't add any value to the program when it executes and\nactually makes it harder to browse the source code using git blame.\n\nMy proposal is to add \"transparent\" commits.\nIf you write git blame these commits will not be shown, instead git\nblame will show a merged version of the code style commit and the\nactual commit while only showing the commit id of the original commit.\n\nA little visualized example:\n\nImagine your first commit is:\n\n58461d5a float yolo(void *i) {\n58461d5a   return (float)*i;\n58461d5a }\n\nAnd you want it to change to (float) *i, so you patch it and the blame\nhistory looks now like this:\n\n58461d5a float yolo(void *i) {\n263da519   return (float) *i;\n58461d5a }\n\nBut what you really want to have when you do a git blame is this:\n\n58461d5a float yolo(void *i) {\n58461d5a   return (float)*i;\n58461d5a }\n\nI hope I expressed myself clearly enough.\nMaybe this was already proposed, but I couldn't find anything in the archives.\n"},{"id":"245406","messageId":"53B6C7AC.7000701@gmail.com","threadId":"37057","inReplyTo":"CAAwotL2a=2syXMCjPsNB9Tzaw1Rrr4UqDyLX9+JYDE-izpJnLg@mail.gmail.com","subject":"Re: Idea, Transparent commits, easier \"code style\" commits","fromName":"Stefan Beller","fromEmail":"stefanbeller@gmail.com","sentAt":"2014-07-04T15:26:36Z","receivedAt":"2014-07-04T15:26:36Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On 04.07.2014 15:12, Andrius Bentkus wrote:\n> I have worked on projects which only after a while (a year or so)\n> established a consistent code style.\n> After the consensus was established there was still some code left\n> which did not fit the newly established standard.\n> Now the problem is, if I create a new patch to actually fix it, it\n> will pollute the blame history.\n> And most of the projects just reject these kind of patches because of this.\n> \n> Imagine that you would have a type conversion \"(int)value\" and wanted\n> it to change to \"(int) value\".\n> The patch will have hundreds of occurrences of this one line changes\n> and will make the git blame look like swiss cheese.\n> It doesn't add much information to the line (you'd rather have\n> technical explanations in the commit) and actually hides all the\n> original comments of the line.\n> \n> So you kinda want to have that style fix patch because inconsistent\n> code style just triggers your OCD, but you can't do anything about it\n> because it doesn't add any value to the program when it executes and\n> actually makes it harder to browse the source code using git blame.\n> \n> My proposal is to add \"transparent\" commits.\n> If you write git blame these commits will not be shown, instead git\n> blame will show a merged version of the code style commit and the\n> actual commit while only showing the commit id of the original commit.\n> \n> A little visualized example:\n> \n> Imagine your first commit is:\n> \n> 58461d5a float yolo(void *i) {\n> 58461d5a   return (float)*i;\n> 58461d5a }\n> \n> And you want it to change to (float) *i, so you patch it and the blame\n> history looks now like this:\n> \n> 58461d5a float yolo(void *i) {\n> 263da519   return (float) *i;\n> 58461d5a }\n> \n> But what you really want to have when you do a git blame is this:\n> \n> 58461d5a float yolo(void *i) {\n> 58461d5a   return (float)*i;\n> 58461d5a }\n> \n> I hope I expressed myself clearly enough.\n> Maybe this was already proposed, but I couldn't find anything in the archives.\n\nCheck the -w option of blame\nhttp://git-scm.com/docs/git-blame\nto fix it while blaming.\n\nOr you need to rewrite the history (a bad idea if the history is\npublished to collegues or on the internet) and squash your fixes into\nthe original commits.\n(see git rebase for that)\n\nBut re-reading your mail, you would like to propose a 3rd way?\nSo when commiting the fixup, you want to add a flag, which tells git\nit's just a fixup commit, which should not be shown, when blaming, but\nrather their parent for the lines in question.\nThat's an interesting idea.\n\nStefan\n"},{"id":"245441","messageId":"CAAwotL3vtkjVO5Zqz+w_gNSS0OAovUfukK8=-Df9K4ZybzNh0A@mail.gmail.com","threadId":"37057","inReplyTo":"53B6C7AC.7000701@gmail.com","subject":"Re: Idea, Transparent commits, easier \"code style\" commits","fromName":"Andrius Bentkus","fromEmail":"andrius.bentkus@gmail.com","sentAt":"2014-07-06T11:44:35Z","receivedAt":"2014-07-06T11:44:35Z","isPatch":false,"sender":{"key":"andrius.bentkus@gmail.com","avatar":null},"body":"-w looks good for my very specific whitespace case, but imagine you\nare adding or removing parenthesis like, it is still codestyle but -w\ndoesn't cut it anymore.\n\nSo yes, I want a flag!\n\nWell, if I think about it, the tools can implement themselves.\n\nThey just have to look into the commit message and look for\n\"#codestylefix\" or whatever other string.\n\nOn Fri, Jul 4, 2014 at 5:26 PM, Stefan Beller <stefanbeller@gmail.com> wrote:\n> On 04.07.2014 15:12, Andrius Bentkus wrote:\n>> I have worked on projects which only after a while (a year or so)\n>> established a consistent code style.\n>> After the consensus was established there was still some code left\n>> which did not fit the newly established standard.\n>> Now the problem is, if I create a new patch to actually fix it, it\n>> will pollute the blame history.\n>> And most of the projects just reject these kind of patches because of this.\n>>\n>> Imagine that you would have a type conversion \"(int)value\" and wanted\n>> it to change to \"(int) value\".\n>> The patch will have hundreds of occurrences of this one line changes\n>> and will make the git blame look like swiss cheese.\n>> It doesn't add much information to the line (you'd rather have\n>> technical explanations in the commit) and actually hides all the\n>> original comments of the line.\n>>\n>> So you kinda want to have that style fix patch because inconsistent\n>> code style just triggers your OCD, but you can't do anything about it\n>> because it doesn't add any value to the program when it executes and\n>> actually makes it harder to browse the source code using git blame.\n>>\n>> My proposal is to add \"transparent\" commits.\n>> If you write git blame these commits will not be shown, instead git\n>> blame will show a merged version of the code style commit and the\n>> actual commit while only showing the commit id of the original commit.\n>>\n>> A little visualized example:\n>>\n>> Imagine your first commit is:\n>>\n>> 58461d5a float yolo(void *i) {\n>> 58461d5a   return (float)*i;\n>> 58461d5a }\n>>\n>> And you want it to change to (float) *i, so you patch it and the blame\n>> history looks now like this:\n>>\n>> 58461d5a float yolo(void *i) {\n>> 263da519   return (float) *i;\n>> 58461d5a }\n>>\n>> But what you really want to have when you do a git blame is this:\n>>\n>> 58461d5a float yolo(void *i) {\n>> 58461d5a   return (float)*i;\n>> 58461d5a }\n>>\n>> I hope I expressed myself clearly enough.\n>> Maybe this was already proposed, but I couldn't find anything in the archives.\n>\n> Check the -w option of blame\n> http://git-scm.com/docs/git-blame\n> to fix it while blaming.\n>\n> Or you need to rewrite the history (a bad idea if the history is\n> published to collegues or on the internet) and squash your fixes into\n> the original commits.\n> (see git rebase for that)\n>\n> But re-reading your mail, you would like to propose a 3rd way?\n> So when commiting the fixup, you want to add a flag, which tells git\n> it's just a fixup commit, which should not be shown, when blaming, but\n> rather their parent for the lines in question.\n> That's an interesting idea.\n>\n> Stefan\n>\n>\n>\n"},{"id":"245442","messageId":"CALZVapnofGirkPBFcgNp4-GZnrNAi3ZXDZA1LM-y3_LYQHksXA@mail.gmail.com","threadId":"37057","inReplyTo":"CAAwotL3vtkjVO5Zqz+w_gNSS0OAovUfukK8=-Df9K4ZybzNh0A@mail.gmail.com","subject":"Re: Idea, Transparent commits, easier \"code style\" commits","fromName":"Javier Domingo Cansino","fromEmail":"javierdo1@gmail.com","sentAt":"2014-07-06T13:37:00Z","receivedAt":"2014-07-06T13:37:00Z","isPatch":false,"sender":{"key":"javierdo1@gmail.com","avatar":"https://gravatar.com/avatar/0f43d4d2e5f4320e8b5e1a46914213c5459dd0de261ab1587f222827f863d727?d=mp&s=160"},"body":"> They just have to look into the commit message and look for\n> \"#codestylefix\" or whatever other string.\n\nIn many projects I have seen, they have a format for commits, such as\n\"docs: Add support for XXX\", \"formatting: Space before parethesis and\nafter comas\", \"tests: ....\" and so on.\n\nMaybe, being able to specify a RegExp would be the way to go, so that\ngit blame did actually ignore those commits.\n"}]}