Oh, of course, that makes sense, you’re right. Does git grep actually do this, or were you thinking of git log or git blame? The git grep command by default is searching for a string in the working directory, not in the commit history. I do that using the “pickaxe” git log -S, or when I don’t have a substring I use git blame or git gui blame.
(Edit: I see that yes git grep can search history if you pipe in a git rev-list command. Is that what you do? Note the trivial workaround with git grep is to put variable whitespace in the regex you’re searching for. If you aren’t looking for a substring with spaces in them, maybe use the much simpler git log -S command?)
Good news: the pickaxe command ignores whitespace changes by default, it only shows you when the substring itself was changed. And git blame takes a -w flag so you can ignore these whitespace changes. -M can help too. First Google result for “git blame ignore whitespace”: https://coderwall.com/p/x8xbnq/git-don-t-blame-people-for-ch...
Git gui has a menu option to ignore whitespace changes too, if you’re spelunking through changes on a given line an don’t have an exact substring change you’re looking for.
So hypothetically, if you had version control tools that truly and completely took care of not showing you whitespace changes, and you were free to reformat your code any way you like without causing any trouble at all, if you had complete freedom, what would you want out of your text formatting tools?
Hey that’s good; git log -S doesn’t show you whitespace changes.
I’m not sure I follow, what does consistent mean to you, can you elaborate? Is that consistency something you have a hard time getting right now because of source control issues? I guess I was wondering about whether you had a wish list for formatting, things that you don’t have but would take if you knew it wouldn’t cause any issues with source control. Do you use clang-format, or any other auto-formatters on your team?
