Hacker News Reader

Comment by pdw | Hacker News Reader

> At a previous company, there was an “infamous” commit in our main repository. The commit was about 10 years old, and it replaced every tab with 4 spaces.

If have commits like this, add the ids to a file `ignorerevs`, and then tell git about it:

   git config --local blame.ignoreRevsFile ignorerevs

Then at least `git blame` will still give useful results. (This is a relatively new git feature, added a year or two ago.)

View on HN

Depending on the size of the team and how much agreement you can get on the importance of such a change, I think the better way to do this on an older repository is to get everyone to nuke their checkouts and use git-filter-branch to rewrite the history so that nobody ever used tabs.

https://stackoverflow.com/questions/58042532/how-can-i-clang...

git-filter-repo is now recommended over -branch by the docs

With the unfortunate side effect of invalidating external refs for instance in your issue tracker or code review tool.

git-filter-branch is going to take forever, use filter-repo

10 years ago would probably long enough ago to not care for me.

But wouldn’t the standard -w be enough to ignore most of this commit.

But I used ignoreRevs in repositories that messed up their history by using an automatic indenter with atrocious settings.

Unfortunately -w won't help you with patch, which uses character positions. But certainly helps with searching.

In addition, if their code is python, -w would incorrectly ignore legitimate changes

do you have a realistic example?

A simple one would be:

    total = 0
    for value in list:
       total += value
       return total

vs.

    total = 0
    for value in list:
       total += value
    return total

ah, fixing a bug, ok. I was trying to think of two hypothetical correctly functioning programs identical but for whitespace, and thinking that was probably pretty rare.

Well the first one simply returns the first value of the list, which can be correct. I just gave the variables names that turned this into a bugfix.

I don't see any sane reason you'd intentionally access the first element only of a list by using a for loop with a non-conditional return. But anyway okeydoke. I do wonder if there are any realistic non-bugfix refactors/enhancements that would result in a whitespace-only change, or in general how often in a real codebase you are going to get a whitespace-only commit diff. But yeah, I understand it is possible, cool.

> 10 years ago would probably long enough ago to not care for me.

Hm, especially for the case of blaming (mostly to figure out why something was done a certain way) I frequently happen upon 10+ year old commits. This happens both in open-source projects, as well as at work (where we don't use git, but the same concepts apply).

Wow, this is incredible! I convinced my team to adopt Prettier for many of our repositories. The only real criticism was that our git history would be cluttered since it would reformat all of our code. This seems like the perfect solution.

When our code was well formatted and reviewed by professionals to show intent, I do not want a robot tampering with it for no good reason, especially if it blindly makes big diffs out of small changes.

Nice! Is there a way to check this into a repository (a la .gitigore)?

You can specify a file with of such commits with --ignore-revs-file, and of course check in that file. Naming that file .git-blame-ignore-revs seems to be a convention I've seen more than once.

Still need to specify the file yourself, so hopefully someone can point out the missing magic to have git pull in .git-blame-ignore-revs on its own.

A shell alias?

That's what the blame.ignoreRevsFile [0] config option is for.

[0] https://git-scm.com/docs/git-config#Documentation/git-config...

Yes but you can't check set git config from a repo unfortunately because some things in it would cause security issues.

banana_giraffe was asking for a way to set it up automatically so users don't have to do anything.

This looks like a job for https://akrabat.com/ignoring-revisions-with-git-blame/

That says to list all the annoying commits in a file, then use a new-ish (Git version 2.23) Git feature to ignore all those commits when doing git blame.

Notice that one of the comments in that article says how to get everyone to use that ignore file, when using GitLens with VSCode.

Just git blame -w to ignore whitespace. There's also an equivalent git config option.

Who gives a shit about a single commit that converts tabs-to-spaces? How is this a problem in any way?

The real problem here is that “git blame” is a garbage tool. Perforce has “timelapse view” that is radically better than any historical view I’ve seen in Git/Hg.

With respect to this issue, git just needs to suck less.

You answered your own question. Git blame is a pretty crappy tool but it's a tool that a lot of people use nevertheless. If you have a commit that converts tabs to spaces, then the blame for pretty much every single line will be lost before that point.

Does Git not offer a way to view the blame from an earlier version? This would let you skip past the wall.

My company has a web tool for browsing the repo that allows this. It’s still inferior to Perforce timelapse view. But it’s not a hard blocker.

Yea, you just have to checkout the version of that file from before the white spaces commit. Then run git blame on it.

    git blame WS_COMMIT^ -- FILE

You’ll need to change the file name, though, if it’s been renamed since the whitespace change.

yes of course, instead of git blame HEAD file you just specify whichever ref you want

Reply on news.ycombinator.com