Re: [PATCH] blame: fix unblamable and ignored lines in porcelain mode
- From
Karthik Nayak <karthik.188@gmail.com>
- Date
- Mar 24, 2025, 19:56 UTC
- Message-ID
- <CAOLa=ZR9f=TiZ7ezNWOMwTqbkjiBYa_4B_zjiA8jBQ4nkEgqqQ@mail.gmail.com>
- In-Reply-To
- <xmqqzfhbrb78.fsf@gitster.g>
Junio C Hamano <gitster@pobox.com> writes:
Show 36 quoted lines
> Karthik Nayak <karthik.188@gmail.com> writes:
>
>> However, this option was never extended to the porcelain mode of
>> 'git-blame(1)'. Since the documentation does not indicate this
>> exclusion, it is a bug.
>
> I agree it is a bug when people added ignore or unblamable support
> that they did not _consider_ what to do with their new pieces of
> information to help porcelain writers. It is not a bug in the code
> per-se, but it is a bug in the brain of these people ;-)
>
> But prefixing random garbage to the commit object name line in the
> porcelain mode output does not sound like the right solution to the
> bug, either.
>
> When enhancing an existing output format, make sure that your
> changes will have minimum empact to existing parsers that do not
> know about your extension. It is reasonably expected that existing
> Porcelain scripts reading from --porcelain mode output works by
>
> - Recognizing a line that match "^[0-9a-f]{40} \d+ \d+ \d+$" and
> take it as the beginning of a new record;
>
> - Collect all info lines before the payload line. Lines that
> describe per-commit information are not repeated if it is already
> shown, so remember them when you see the commit for the first
> time, and recall them when you recognize the commit you already
> saw.
>
> - A payload line is indented with HT and terminates the record.
>
> If you start to add unrecognizable garbage to the line with very
> well known fixed format that is used as record delimiter, you would
> break the existing parsers, which is not a very nice thing to do.
> Are there other and better ways you can think of to add new pieces
> of information like this in a way with less severe damage?Fair enough, I was having this argument and convinced myself because the option is an explicit setting. So users who have 'blame.markIgnoredLines' or/and 'blame.markUnblamableLines' set and are using one of the 'ignore-rev' options would be expecting either an '?' or a '*' as mentioned in the documentation.
Let's me figure if there is a more backward-compatible way of doing this.