Am 30.09.20 um 23:15 schrieb Harrison McCullough:
> What did you do before the bug happened?
>
> 1. Commit changes to <FILE>
> 2. Observe that this commit has a hash of <HASH>, e.g. through git rev-parse
> HEAD
> 3. Run `echo <HASH> > .git-blame-ignore-revs`
> 4. Run `git config blame.ignoreRevsFile .git-blame-ignore-revs`
> 5. Run `git blame <FILE>`
> 6. Run `git blame --ignore-revs-file=.git-blame-ignore-revs <FILE>`
> 7. Run `git blame --ignore-rev=<HASH> <FILE>`
>
>
> What did you expect to happen? (Expected behavior)
>
> The three git blame commands should attribute each line of the source file to a
> commit, but none of those commits should be the one specified by <HASH>.
>
>
> What happened instead? (Actual behavior)
>
> All three git blame commands included lines attributed to <HASH>.
>
>
> What's different between what you expected and what actually happened?
>
> The commit identified by <HASH> was not ignored.
Well, your expectation sounds reasonable, but apparently it's not that
easy. Consider this sentence from the description of --ignore-rev on
the manpage of git blame:
If the `blame.markUnblamableLines` config option is set, then those
lines touched by an ignored commit that we could not attribute to
another revision are marked with a '*'.
So some commits just cannot be ignored by the current version of git
blame. The commit message of ae3f36dea1 (blame: add the ability to
ignore commits and their changes, 2019-05-15), which introduced that
feature, mentions an example. And this silly script finds that 365 of
the 765 commits blamed for Git's own Makefile are examples as well:
file=Makefile
rev=v2.28.0
hashes=$(git blame "$rev" "$file" | awk '{print $1}' | sort -u)
echo "$hashes" | wc -l
for hash in $hashes
do
if git blame --ignore-rev=$hash "$rev" "$file" | grep -q "^$hash "
then
echo $hash
fi
done | wc -l
I don't know if these revisions are not ignored due to bugs or because
the feature just isn't strong enough, yet, but I would expect your
particular case to be represented by at least one of these...
> Anything else you want to add:
>
> I tried this in a brand new repository and everything worked as expected. I do
> not know why it is only failing in this repository. It is a large repository I
> use for work, but I'm using the same version of Git in both places.
... so this might not be a problem, as finding public examples seems
to be easy.
>
>
> [System Info]
> git version:
> git version 2.28.0
> cpu: x86_64
> no commit associated with this build
> sizeof-long: 8
> sizeof-size_t: 8
> shell-path: /bin/sh
> uname: Darwin 18.7.0 Darwin Kernel Version 18.7.0: Mon Apr 27 20:09:39
> PDT 2020; root:xnu-4903.278.35~1/RELEASE_X86_64 x86_64
> compiler info: clang: 11.0.0 (clang-1100.0.33.17)
> libc info: no libc information available
> $SHELL (typically, interactive shell): /usr/local/bin/bash
>
>
> [Enabled Hooks]
> post-commit
> post-checkout
> post-merge
> pre-push
>
