On Tue, Oct 22, 2024 at 2:49 AM Abhijeetsingh Meena <abhijeetsingh.github@xxxxxxxxx> wrote: > Hi Eric, Kristoffer, and Phillip, > > A few days ago, I sent a detailed email addressing each of your > questions and suggestions individually. Before proceeding with v3, > I’d like to consolidate my thoughts on the next possible approach > to respect '.git-blame-ignore-revs' based on Kristoffer's conceptual > explanation. Although I asked several questions (which popped into my head) during my review of the patch, I don't have much to add to the discussion since I don't use this feature and either wasn't aware of it or forgot about it until your patch arrived. Phillip is off-list through the end of the month, so it is unlikely that he will respond before then. The general idea of implementing this new behavior via config-list may indeed be a reasonable way to make it more well-integrated with the existing methods of specifying ignore-revs. However, that's also an implementation detail which seems less important presently than these possible open concerns (unless they've been answered elsewhere), all of which have to do with forward and backward compatibility... * Will automatic reading of top-level .git-blame-ignore-revs cause any unexpected behaviors for existing users who (presumably) are using it via configuration? It seems unlikely, but the implementation ought to be careful to process .git-blame-ignore-revs only once. * Will automatic reading of .git-blame-ignore-revs cause unexpected behavior for people who have not set up the configuration? In other words, maybe some projects have a .git-blame-ignore-revs but some users don't want it consulted by default, thus avoid setting the configuration. * It sounds like you want to punt on the idea of cumulatively processing .git-blame-ignore-revs files from the current subdirectory up to the project root (as .gitignore works), but can this be done in such a way that we don't break user's expectations or automations if such behavior is eventually implemented?
