This noise shows up in git greps. It's not as superficial as you think.

It’s true that searching for something will return the lines as they’re formatted. I’m certainly curious to hear how whitespace changes over time in git grep causes problems, what the problems are, and what the alternatives are. I can imagine reasons that might happen, but that particular example isn’t something I’ve experienced myself or heard of before, so I don’t know if I’m discounting it unfairly. Like I said in defense of your comment higher up, I see why people like you react to certain formatting tools this way, but it turns out that tools that insert and delete line breaks are far more serious when it comes to workflow implications than tools that only insert spaces or tabs to get vertical alignment, so it’s worth making that distinction right from the start.

I don’t think vertical alignment is going away, I think it will become far more common, and that our tools will catch up. My prediction is that git and other source control systems become more tolerant of formatting changes, and that developers in general will learn more workflow techniques for allowing whitespace churn.

For me, having the alignment and making the code more readable to me is more valuable than the minor inconveniences with source control that it might cause, and on top of that I’ve learned that there are ways to mitigate most of the issues. I’m not arguing that it doesn’t cause any problems, I’m only saying that it’s worth prioritizing for me, that there are things you can learn to do about it, that the tools give you options and will probably improve, and that vertical alignment in particular does far less damage that line-breaking reflows like clang-format impose… and use of clang-format is pretty widespread and standard in my experience.

Code does change over time. Refactoring happens. Variables are renamed. Comments change over time. We don’t ask people to avoid writing code or adding comments because the changes appear in git diff or grep, or even because they might cause merge conflicts… those things are considered an acceptable cost of doing business in software. I don’t see any reason to treat good formatting differently, within reason.

If I'm searching for commits that change lines with substring X I'm not interested in seeing commits that move variables four spaces to the left.

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?

Probably thinking about git log -S.

> what would you want out of your text formatting tools?

Consistent white space rules when reading from left to right.

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?