Thread: annoyance with .git-blame-ignore-revs
I like the ignore-revs file, but I run into a problem with my setup:
because I keep checkouts of all branches as worktrees, then all branches
share the same .git/config file. So if I put the recommended stanza for
[blame] in it, then 'git blame' complains in branches older than 13,
since those don't have the file:
$ git blame configure
fatal: could not open object name list: .git-blame-ignore-revs
My first workaround was to add empty .git-blame-ignore-revs in all
checkouts. This was moderately ok (shrug), until after a recent `tig`
upgrade the empty file started to show up in the history as an untracked
file.
So I'm now by the second workaround, which is to move the [blame]
section of config to a separate file, and use a [includeIf] sections
like this:
[includeIf "onbranch:master"]
path=config.blame.inc
[includeIf "onbranch:REL_1{4,5,6,7,8,9}_STABLE"]
path=config.blame.inc
[includeIf "onbranch:REL_2*_STABLE"]
path=config.blame.inc
This is quite ugly, and it doesn't work at all if I run `git blame` in a
worktree that I create for development purposes (I don't name those
after the upstream PG branch they're based on).
Anybody has any idea how to handle this better?
A viable option would be to backpatch the addition of
.git-blame-ignore-revs to all live branches. Would that bother anyone?
--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
> On 11 Jul 2022, at 18:31, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote: > A viable option would be to backpatch the addition of > .git-blame-ignore-revs to all live branches. Would that bother anyone? I wouldn't mind having it backpatched. -- Daniel Gustafsson https://vmware.com/
Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> A viable option would be to backpatch the addition of
> .git-blame-ignore-revs to all live branches. Would that bother anyone?
Only if we had to update all those copies all the time. But
I'm guessing we wouldn't need a branch's copy to be newer than
the last pgindent run affecting that branch?
regards, tom lane
On Mon, Jul 11, 2022 at 12:30 PM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote: > Anybody has any idea how to handle this better? > > A viable option would be to backpatch the addition of > .git-blame-ignore-revs to all live branches. Would that bother anyone? +1. I was thinking of suggesting the same thing myself, for the same reasons. This solution is a good start, but it does leave one remaining problem: commits from before the introduction of .git-blame-ignore-revs still won't have the file. There was actually a patch for git that tried to address the problem directly, but it didn't go anywhere. Maybe just backpatching the file is good enough. -- Peter Geoghegan
> On 11 Jul 2022, at 21:35, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Alvaro Herrera <alvherre@alvh.no-ip.org> writes: >> A viable option would be to backpatch the addition of >> .git-blame-ignore-revs to all live branches. Would that bother anyone? > > Only if we had to update all those copies all the time. But > I'm guessing we wouldn't need a branch's copy to be newer than > the last pgindent run affecting that branch? We shouldn't need that, if we do it would indicate we did cosmetic-only commits in backbranches which IIUC isn't in line with project policy (or at least rare to the point of not being a problem). -- Daniel Gustafsson https://vmware.com/
On Mon, Jul 11, 2022 at 12:36 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > Only if we had to update all those copies all the time. But > I'm guessing we wouldn't need a branch's copy to be newer than > the last pgindent run affecting that branch? I wouldn't care very much if the file itself was empty in the backbranches, and remained that way -- that would at least suppress annoying error messages on those branches (from my text editor's git blame feature). You might as well have the relevant commits when you backpatch, but that's kind of not the point. At least to me. In any case I don't see a need to maintain the file on the backbranches. -- Peter Geoghegan
On Mon, Jul 11, 2022 at 12:30 PM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote: > $ git blame configure > fatal: could not open object name list: .git-blame-ignore-revs > > My first workaround was to add empty .git-blame-ignore-revs in all > checkouts. This was moderately ok (shrug), until after a recent `tig` > upgrade the empty file started to show up in the history as an untracked > file. Ping? Would be nice to get this done soon. I don't think that it requires a great deal of care. If I was doing this myself, I would probably make sure that the backbranch copies of the file won't reference commits from later releases. But even that probably doesn't matter; just backpatching the file from HEAD as-is wouldn't break anybody's workflow. Again, to reiterate: I see no reason to do anything on the backbranches here more than once. I mentioned already that somebody proposed a patch that fixes the problem at the git level, which seems to have stalled. Here is the discussion: https://public-inbox.org/git/xmqq5ywehb69.fsf@gitster.g/T/ ISTM that we're working around what is actually a usability problem with git (imagine that!). I think that that's fine. Just thought that it was worth acknowledging it as such. We're certainly not the first people to run into this exact annoyance. -- Peter Geoghegan
On 2022-08-04 Th 20:35, Peter Geoghegan wrote: > On Mon, Jul 11, 2022 at 12:30 PM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote: >> $ git blame configure >> fatal: could not open object name list: .git-blame-ignore-revs >> >> My first workaround was to add empty .git-blame-ignore-revs in all >> checkouts. This was moderately ok (shrug), until after a recent `tig` >> upgrade the empty file started to show up in the history as an untracked >> file. > Ping? Would be nice to get this done soon. I don't think that it > requires a great deal of care. If I was doing this myself, I would > probably make sure that the backbranch copies of the file won't > reference commits from later releases. But even that probably doesn't > matter; just backpatching the file from HEAD as-is wouldn't break > anybody's workflow. > > Again, to reiterate: I see no reason to do anything on the > backbranches here more than once. > > I mentioned already that somebody proposed a patch that fixes the > problem at the git level, which seems to have stalled. Here is the > discussion: > > https://public-inbox.org/git/xmqq5ywehb69.fsf@gitster.g/T/ > > ISTM that we're working around what is actually a usability problem > with git (imagine that!). I think that that's fine. Just thought that > it was worth acknowledging it as such. We're certainly not the first > people to run into this exact annoyance. let's just backpatch the file and be done with it. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
On 2022-Aug-05, Andrew Dunstan wrote: > let's just backpatch the file and be done with it. I can do that in a couple of hours. -- Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/ "You don't solve a bad join with SELECT DISTINCT" #CupsOfFail https://twitter.com/connor_mc_d/status/1431240081726115845
On 2022-Aug-05, Alvaro Herrera wrote: > On 2022-Aug-05, Andrew Dunstan wrote: > > > let's just backpatch the file and be done with it. > > I can do that in a couple of hours. Done. Thanks! -- Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/ "La rebeldía es la virtud original del hombre" (Arthur Schopenhauer)