Re: [PATCH 0/5] backfill: accept revision arguments

[Patrick Steinhardt <ps@pks.im>]

On Thu, Mar 19, 2026 at 08:59:01AM -0400, Derrick Stolee wrote:
> On 3/19/2026 5:54 AM, Patrick Steinhardt wrote:
> > I think especially blaming is a bit of a sore spot -- downloading blobs
> > one by one simply doesn't cut it there. I wonder whether we can easily
> > use the backfill mechanism to fetch blobs automatically in git-blame(1)
> > so that the user doesn't need to know about git-backfill(1) at all?
> 
> I've thought about this a bit, and I'm not sure that we want to run
> 'git backfill' directly. Instead, it would be nice if we did a "staged"
> algorithm for 'git blame':
> 
> 1. Walk commits according to the pathspec to collect the commits that
>    changed the path.
> 
> 2. Collect the list of blob OIDs that will be needed for computing diffs
>    for the line-tracking algorithm.
> 
> 3. In batches, download groups of missing blobs and then process them
>    for line-tracking diffs. (Stop if all lines are blamed; continue to
>    next batch if more lines are needed.)
> 
> This would be a significant rewrite of the blame algorithm, though. I
> briefly considered this approach about a year ago and decided it would
> be easier to start with 'git backfill' and see whether that satisfies
> most needs.
> 
> The biggest reason to maybe avoid 'git backfill HEAD -- <path>' before
> _every_ blame operation is that this will add overhead on repeated
> calls that may be obnoxious in its own way. Maybe doing an opt-in
> 'git blame --backfill <path>' would make it easier for users to opt-in
> when they want to.

That's fair. I fully agree that just blindly doing this would be likely
be inefficient. Ideally, the batching logic would only kick in whenever
we see a missing object.

Anyway, this definitely doesn't have to be part of this series, I was
mostly wondering how hard it is to do.

Thanks!

Patrick