Horton

Thread

Commits

  1. Backpatch addition of .git-blame-ignore-revs

  1. annoyance with .git-blame-ignore-revs

    Alvaro Herrera <alvherre@alvh.no-ip.org> — 2022-07-11T16:31:38Z

    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/

  2. Re: annoyance with .git-blame-ignore-revs

    Daniel Gustafsson <daniel@yesql.se> — 2022-07-11T19:32:22Z

    > 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/

  3. Re: annoyance with .git-blame-ignore-revs

    Tom Lane <tgl@sss.pgh.pa.us> — 2022-07-11T19:35:58Z

    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

  4. Re: annoyance with .git-blame-ignore-revs

    Peter Geoghegan <pg@bowt.ie> — 2022-07-11T19:37:26Z

    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

  5. Re: annoyance with .git-blame-ignore-revs

    Daniel Gustafsson <daniel@yesql.se> — 2022-07-11T19:38:07Z

    > 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/

  6. Re: annoyance with .git-blame-ignore-revs

    Peter Geoghegan <pg@bowt.ie> — 2022-07-11T19:39:48Z

    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

  7. Re: annoyance with .git-blame-ignore-revs

    Peter Geoghegan <pg@bowt.ie> — 2022-08-05T00:35:21Z

    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

  8. Re: annoyance with .git-blame-ignore-revs

    Andrew Dunstan <andrew@dunslane.net> — 2022-08-05T14:07:00Z

    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

  9. Re: annoyance with .git-blame-ignore-revs

    Alvaro Herrera <alvherre@alvh.no-ip.org> — 2022-08-05T14:17:13Z

    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

  10. Re: annoyance with .git-blame-ignore-revs

    Alvaro Herrera <alvherre@alvh.no-ip.org> — 2022-08-05T17:38:38Z

    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)