Adam Simpkins <adam@xxxxxxxxxxxxxxxx> writes: > The old code took care of these cases for CMIT_FMT_ONELINE, but not for > CMIT_FMT_USERFORMAT. For CMIT_FMT_USERFORMAT, show_log() left each > entry without a terminating newline. The next call to show_log() would > then try to print an extra blank line between entries. The log family traditionally defined LF (or NUL when -z is in effect) as separator between each pair of entries, not as terminator after each entry. This was because it would make much more sense to use separator semantics when "git log -2" and "git log -1" is asked for. The former gives the tip, separator (typically an extra LF), and the second, while the latter just shows the tip. Neither case give extra LF after the last entry. This worked only because each entry were supposed to end with its own LF, so separator literally "separated" each entry with an extra blank line. ONELINE however is special cased, because it makes no sense to give an extran blank line to separate each entry. Compactness is the point of the format. Switching separator semantics to terminator semantics in USERFORMAT unconditionally is a bit problematic, because the userformat can be used to format multi-line entries and in that case you may want the usual "extra blank to separate" semantics, but it often is used to define an alternate oneline format, in which case you do want terminator semantics instead. I suspect that --pretty=format: (i.e. userformat) should have a way to explicitly tell which is wanted. Perhaps we can keep the separator semantics not to break existing users, and introduce a dummy expand item (say, '%_') and when it appears in the pattern it would ask for the terminator semantics instead? In any case, I'm happy to see that somebody started looking into this, as this "separator vs terminator" issue in userformat has been nagging me for quite a while. It might be good idea to have the change independently from the graph extension first and then build the graph stuff on top of the solidified base. I dunno... -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
