On Sun, Sep 06, 2020 at 11:54:42PM -0700, Junio C Hamano wrote: > > I gave a reason for the reference format, at least. > > > > Would you be fine with a patch that just allows to override the > > reference format (for the stated reasons)? > > Your "reason" read pretty much the same as "I want reference to do > something else", but that leads to "depending on the configuration, > even built-in names that are well known to all Git users behave > differently---the users lose common reference (no pun intended)". I think there is some value in having names and rough semantics that are well-known to all Git users (and scripts), but whose exact output is not set in stone. So a name like "reference" becomes a rendezvous point between a script like gitk and the user. It is a shorthand for "reference a commit in a human-readable way according to the user or project preferences". The script wants to read that value, and the user wants to specify it. You could accomplish something similar by having gitk look up pretty.userReference, and defaulting to something sensible if it's not defined. For a big script like gitk that's not too much of an imposition. But it's awfully convenient to be able to just say --format=reference in any script and get the user's preferred format. That's where I think your pretty.kernel example falls down; both the repo and the script have to agree that the name "kernel" exists. > Also I am not sure how your reason applies specifically to the > reference format. It would be widely applicable to other formats > like 'short' and 'oneline' in that depending on projects' and > personal preference, people may want "something like X but not > exactly X" for all the built-in formats. The things that may make "reference" different are: - it's new-ish, so there's less chance of historical dependencies on it (this is a bit hand-wavy, of course; it has been in released versions. On the other hand, people may well have been using pretty.reference for this already, and we made it stop working when we added "reference"). - from the start, the point was for it to be a human-readable format (it's not even unambiguously parseable anyway). So of any of the formats, it seems like the most likely candidate for such a feature (setting "pretty.raw" would be a pretty big foot-gun, for instance). I don't like the inconsistency it introduces between formats, though. Here's a slightly different proposal. I'm not sure if I like it or not, but just thinking out loud for a moment. The issue is that we're worried the consumer of the output may be surprised by a user-configured pretty format. Can we give them a way to say "I don't care about the exact output; pick what the user configured for this name, or some sane default". I.e., something like: git log --format=loose:reference ? That would let pretty.reference override the built-in name, but the behavior of plain "--format=reference" would continue to ignore it. It's a little more annoying for a script to specify, but not nearly as annoying as: format=$(git config pretty.customReference || echo "%h (%s, %d)") git log --format="%format" -Peff
