Christian Couder <christian.couder@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxxxxxxx/ > 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.
