Re: [PATCH v4] fast-(import|export): improve on commit signature output format

[Junio C Hamano <gitster@pobox.com>]

Christian Couder <christian.couder@gmail.com> writes:

tldr; 2 brief requests.  Please

 - Be gentle to people and expect that it is normal for them to be
   off of the list for a few weeks (or even more), not able to give
   a timely comments;

 - Fully stand behind your own patch (unless it is an RFC), even if
   some of the idea came from elsewhere.

>> Why would it need to say what type of signature it is?  Don't the
>> ascii armor lines have e.g. "----BEGIN PGP SIGNATURE----" and "----END
>> PGP SIGNATURE----" around it, which fast-import can read as well as
>> fast-export?  Is the idea that we strip those lines and now need to
>> replace the information we lost?
>
> In https://lore.kernel.org/git/aAq1nvcPRlIPal5l@tapette.crustytoothpaste.net/
> brian said:
>
> "These should be separate fields: one for the hash algorithm and one for
> the protocol.  Alternatively, we can just keep the hash algorithm field
> and parse the protocol by reading the first line, which will differ for
> different protocols."
>
> It would have been nice if you had then said that you prefer not to
> have the protocol.

Let's remember to be gentle for those who give varluable feedbacks
but may not be always on this list.  A late comment on a topic that
has not hit 'next' is much better than a late comment after the
topic hits 'next', or no comment at all.

Also, even if the idea came from somebody else, if you agreed to the
idea and made it part of your submission, then it would be better to
explain it in your own words, in the most appropriate way to answer
the question asked (e.g. the original from Brian and the question by
Elijah may have stress on different aspect of the problem).

> My opinion was that it was better for tools processing fast-export
> output to have the protocol as they have to parse the "gppsig ..."
> line anyway. So it should be easier for them than to parse the ascii
> armor lines.

And if you do not agree with Brian's, perhaps discuss a bit more to
(1) either convince yourself that Brian's idea is better and rewrite
your code to adopt the idea, or (2) explain the reason why your "the
importer reads and parses anyway" is better design and stick to it.

> ...
> Yeah, I would have been happy if we could have been aligned with the
> goals of the format and the fields earlier, but better late than
> never.
>
>> Thanks for working on this topic.
>
> Thanks for reviewing.

Thanks.