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 stefanbel...@gmail.com 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
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
Idea, Transparent commits, easier code style commits
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.
--
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
