Welcome to Software Development on Codidact!
Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.
How to keep git blame ignored commits up to date?
When I make a separate commit for code cleanup / style changes, I can suppress that commit from git blame so that I can follow a file's history easily without getting distracted by pure style changes. I do that by putting the cleanup commit's hash in a file and tell git to ignore those commits for blaming purposes:
echo $the_full_hash >> .git-blame-ignore-revs
git config blame.ignoreRevsFile .git-blame-ignore-revs
But at the time I make my cleanup commit, I don't have the hash yet, so I need an extra commit to update .git-blame-ignore-revs. I'd rather have that in the same commit.
Even if I can get the hash of my current working copy changes, adding that hash to .git-blame-ignore-revs would modify what I am committing, resulting in a different hash, as .git-blame-ignore-revs is also checked in.
On top of that, if I make 2 commits and then use github's PR squashing merge, my hash in .git-blame-ignore-revs is wrong as only the squashed commit makes it into git, not the individual ones.
How do people keep their .git-blame-ignore-revs up to date? Is there a better way than 2 commits?
1 answer
[Disclaimer: This is an alternative workaround, and not really answering your question.]
When blaming files in a git repository in which I am working at the moment, I usually blame from the master branch, or from HEAD, or HEAD^, depending on what I'm interested in. That is, don't start blaming on the working tree, but on some revision.
My git-blame(1) sessions look more or less like this (this is an actual session from February https://github.com/shadow-maint/shadow/issues/939#issuecomment-1933925702):
alx@debian:~/src/shadow/shadow/ts$ git blame HEAD -- lib/strtoday.c | grep DAY
89a7ee7b2 libmisc/strtoday.c (Iker Pedrosa 2023-06-07 14:58:34 +0200 76) return (t + DAY / 2) / DAY;
alx@debian:~/src/shadow/shadow/ts$ git show 89a7ee7b2 -- libmisc/strtoday.c | grep DAY
- return (long) (t + DAY / 2) / DAY;
+ return (t + DAY / 2) / DAY;
alx@debian:~/src/shadow/shadow/ts$ git blame 89a7ee7b2^ -- libmisc/strtoday.c | grep DAY
815ffb7d3 (nekral-guest 2008-06-13 19:48:11 +0000 76) return (long) (t + DAY / 2) / DAY;
alx@debian:~/src/shadow/shadow/ts$ git show 815ffb7d3 -- libmisc/strtoday.c | grep DAY
- return (t + DAY / 2) / DAY;
+ return (long) (t + DAY / 2) / DAY;
- return result / DAY; /* success */
+ return (long) (result / DAY); /* success */
alx@debian:~/src/shadow/shadow/ts$ git blame 815ffb7d3^ -- libmisc/strtoday.c | grep DAY
effd479bf (nekral-guest 2007-10-07 11:45:23 +0000 79) return (t + DAY / 2) / DAY;
effd479bf (nekral-guest 2007-10-07 11:45:23 +0000 139) return result / DAY; /* success */
alx@debian:~/src/shadow/shadow/ts$ git show effd479bf -- libmisc/strtoday.c | grep DAY
- return (t + DAY/2)/DAY;
+ return (t + DAY / 2) / DAY;
- return result / DAY; /* success */
+ return result / DAY; /* success */
alx@debian:~/src/shadow/shadow/ts$ git blame effd479bf^ -- libmisc/strtoday.c | grep DAY
45c6603cc (nekral-guest 2007-10-07 11:44:02 +0000 80) return (t + DAY/2)/DAY;
45c6603cc (nekral-guest 2007-10-07 11:44:02 +0000 142) return result / DAY; /* success */
alx@debian:~/src/shadow/shadow/ts$ git show 45c6603cc -- libmisc/strtoday.c | grep DAY
+ return (t + DAY/2)/DAY;
+ return result / DAY; /* success */
alx@debian:~/src/shadow/shadow/ts$ git log -1 45c6603cc | head
commit 45c6603cc86c5881b00ac40e0f9fe548c30ff6be
Author: nekral-guest <nekral-guest@5a98b0ae-9ef6-0310-add3-de5d479b70d7>
Date: Sun Oct 7 11:44:02 2007 +0000
[svn-upgrade] Integrating new upstream version, shadow (19990709)
BTW, I never used a blame-ignore file. I didn't even know that feature existed. And I don't think it's a good idea: sometimes it's those cosmetic patches the ones that accidentally broke something, so skipping them might be problematic. Anyway, a blame session is usually small (i.e., no more than 10 or 20 commits). It's not like you refactor the same code over and over a hundred times).
0 comment threads
1 comment thread