Re: Idea, Transparent commits, easier "code style" commits

> On 04.07.2014 15:12, Andrius Bentkus wrote:
>> I have worked on projects which only after a while (a year or so)
>> established a consistent code style.
>> After the consensus was established there was still some code left
>> which did not fit the newly established standard.
>> Now the problem is, if I create a new patch to actually fix it, it
>> will pollute the blame history.
>> And most of the projects just reject these kind of patches because of this.
>>
>> Imagine that you would have a type conversion "(int)value" and wanted
>> it to change to "(int) value".
>> The patch will have hundreds of occurrences of this one line changes
>> and will make the git blame look like swiss cheese.
>> It doesn't add much information to the line (you'd rather have
>> technical explanations in the commit) and actually hides all the
>> original comments of the line.
>>
>> So you kinda want to have that style fix patch because inconsistent
>> code style just triggers your OCD, but you can't do anything about it
>> because it doesn't add any value to the program when it executes and
>> actually makes it harder to browse the source code using git blame.
>>
>> My proposal is to add "transparent" commits.
>> If you write git blame these commits will not be shown, instead git
>> blame will show a merged version of the code style commit and the
>> actual commit while only showing the commit id of the original commit.
>>
>> A little visualized example:
>>
>> Imagine your first commit is:
>>
>> 58461d5a float yolo(void *i) {
>> 58461d5a   return (float)*i;
>> 58461d5a }
>>
>> And you want it to change to (float) *i, so you patch it and the blame
>> history looks now like this:
>>
>> 58461d5a float yolo(void *i) {
>> 263da519   return (float) *i;
>> 58461d5a }
>>
>> But what you really want to have when you do a git blame is this:
>>
>> 58461d5a float yolo(void *i) {
>> 58461d5a   return (float)*i;
>> 58461d5a }
>>
>> I hope I expressed myself clearly enough.
>> Maybe this was already proposed, but I couldn't find anything in the archives.
>
> Check the -w option of blame
> http://git-scm.com/docs/git-blame
> to fix it while blaming.
>
> Or you need to rewrite the history (a bad idea if the history is
> published to collegues or on the internet) and squash your fixes into
> the original commits.
> (see git rebase for that)
>
> But re-reading your mail, you would like to propose a 3rd way?
> So when commiting the fixup, you want to add a flag, which tells git
> it's just a fixup commit, which should not be shown, when blaming, but
> rather their parent for the lines in question.
> That's an interesting idea.
>
> Stefan
>
>
>