Junio C Hamano <gitster@xxxxxxxxx> writes:
> Karthik Nayak <karthik.188@xxxxxxxxx> 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.
Attachment:
signature.asc
Description: PGP signature
