git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "René Scharfe" <l.s.r@web.de>
To: Harrison McCullough <mccullough.harrison@gmail.com>, git@vger.kernel.org
Cc: Barret Rhoden <brho@google.com>
Subject: Re: git blame --ignore-rev does not work
Date: Fri, 2 Oct 2020 23:40:27 +0200	[thread overview]
Message-ID: <d805f025-fbfb-0249-a50c-ff857dc2e29d@web.de> (raw)
In-Reply-To: <CAHLeu+x-z4ntmBezcVUWssZrCm03Md6ZR8-ZQmjkeB5YT89caQ@mail.gmail.com>

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
>


  reply	other threads:[~2020-10-02 21:40 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-30 21:15 git blame --ignore-rev does not work Harrison McCullough
2020-10-02 21:40 ` René Scharfe [this message]
2020-10-02 22:44   ` Barret Rhoden
2020-10-02 22:52     ` Harrison McCullough
2020-10-03  0:56       ` Barret Rhoden

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d805f025-fbfb-0249-a50c-ff857dc2e29d@web.de \
    --to=l.s.r@web.de \
    --cc=brho@google.com \
    --cc=git@vger.kernel.org \
    --cc=mccullough.harrison@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).