Re: Idea, Transparent commits, easier "code style" commits
> They just have to look into the commit message and look for > "#codestylefix" or whatever other string. In many projects I have seen, they have a format for commits, such as "docs: Add support for XXX", "formatting: Space before parethesis and after comas", "tests: " and so on. Maybe, being able to specify a RegExp would be the way to go, so that git blame did actually ignore those commits. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Idea, Transparent commits, easier "code style" commits
-w looks good for my very specific whitespace case, but imagine you
are adding or removing parenthesis like, it is still codestyle but -w
doesn't cut it anymore.
So yes, I want a flag!
Well, if I think about it, the tools can implement themselves.
They just have to look into the commit message and look for
"#codestylefix" or whatever other string.
On Fri, Jul 4, 2014 at 5:26 PM, Stefan Beller wrote:
> 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
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
