Git development
 help / color / mirror / Atom feed
From: Ravi Mistry <rmistry@google.com>
To: gitster@pobox.com
Cc: git@vger.kernel.org, phillip.wood@dunelm.org.uk,
	code@khaugsbakk.name,  sunshine@sunshineco.com,
	abhijeet040403@gmail.com, rmistry@google.com
Subject: Re: [PATCH] blame: default to ignoring revisions in .git-blame-ignore-revs
Date: Mon,  5 Oct 2026 21:12:13 +0000	[thread overview]
Message-ID: <20261005211213.1896012-1-rmistry@google.com> (raw)
In-Reply-To: <xmqqse2kma4o.fsf@gitster.g>

"Junio C Hamano" <gitster@pobox.com> writes:

> While wanting consistency is reasonable, the description above does
> not quite match that goal.  If an untracked '.git-blame-ignore-revs'
> file exists at the root of the working tree, or if a tracked one has
> local changes relative to HEAD, the local repository behaves
> differently from hosting sites that operate on the
> 'HEAD:.git-blame-ignore-revs' blob.  It may make more sense to say:
> "If the 'HEAD:.git-blame-ignore-revs' blob exists, it is added as
> the initial element in the list of ignore-revs files.  Other files
> listed in the configuration are also used, but an empty element
> makes all elements that appeared before in the list forgotten."
> This rule should apply whether the repository is bare or not.

Thank you very much for the detailed feedback, Junio! Reading the
committed blob from HEAD instead of the working tree totally makes
sense.

> Somebody has to audit the parser for these files (one unabbreviated
> object name per line, ignoring whitespace and lines starting with
> '#') and ensure that the implementation is truly secure.

I looked through the parser in oidset.c (which we can share for
both the HEAD blob and configured files) and peel_to_commit_oid in
builtin/blame.c. Mostly looks good, IMHO, but there may be two edge
cases we can tighten up:

1. Rejecting lines with embedded NUL bytes via memchr in oidset.c
   (where strchr and the check after parse_oid_hex_algop currently
   stop at the first NUL byte and ignore trailing bytes on the
   line).

2. Passing OBJECT_INFO_SKIP_FETCH_OBJECT and OBJECT_INFO_QUICK in
   peel_to_commit_oid and peeling tags step by step so missing OIDs
   or tag targets do not trigger lazy promisor fetches in partial
   clones.

Does this plan sound good to you for v2?

Thanks,
Ravi

  reply	other threads:[~2026-10-05 21:12 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-11 23:29 [PATCH] blame: default to ignoring revisions in .git-blame-ignore-revs Ravi Mistry via GitGitGadget
2026-09-30 14:59 ` Ravi Mistry
2026-10-05 15:37 ` Junio C Hamano
2026-10-05 21:12   ` Ravi Mistry [this message]
2026-10-07 17:43     ` Junio C Hamano
2026-10-07 18:07       ` Ravi Mistry
2026-10-08 21:07 ` [PATCH v2 0/2] blame: ignore revs in HEAD:.git-blame-ignore-revs by default Ravi Mistry via GitGitGadget
2026-10-08 21:07   ` [PATCH v2 1/2] blame: harden ignore-revs parser and tag peeling Ravi Mistry via GitGitGadget
2026-10-09  5:07     ` Junio C Hamano
2026-10-08 21:07   ` [PATCH v2 2/2] blame: ignore revs in HEAD:.git-blame-ignore-revs Ravi Mistry via GitGitGadget
2026-10-09 20:17     ` Junio C Hamano

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

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

  git send-email \
    --in-reply-to=20261005211213.1896012-1-rmistry@google.com \
    --to=rmistry@google.com \
    --cc=abhijeet040403@gmail.com \
    --cc=code@khaugsbakk.name \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=phillip.wood@dunelm.org.uk \
    --cc=sunshine@sunshineco.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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox