Thanks for backlinking! I had intended to link my SO question and then forgot. That matches what I saw from reading the code as well. As far as I could tell, the `pretty_print_commit` function only calls `repo_format_commit_message` when `pp->fmt == CMIT_FMT_USERFORMAT`, and not at all the built-in formats. Thus, we cannot infer the correct format string equivalent by simply reading the code, which is another reason why I think it's worth documenting the closest format string equivalent and its limitations. Ideally, the format string is powerful enough to replicate the built-in formats, but if it is not, then that is also worth documenting explicitly. References: https://github.com/git/git/blob/ef8ce8f3d4344fd3af049c17eeba5cd20d98b69f/pretty.c#L2282 https://github.com/git/git/blob/ef8ce8f3d4344fd3af049c17eeba5cd20d98b69f/pretty.c#L2294 On Tue, Oct 15, 2024 at 11:06 AM Kristoffer Haugsbakk <kristofferhaugsbakk@xxxxxxxxxxxx> wrote: > > Backlink: > > https://stackoverflow.com/questions/79089206/is-it-possible-to-fully-replicate-the-default-behavior-of-git-log-with-a-format > > I took a look at the code before today with search terms like > > CMIT_FMT_DEFAULT > CMIT_FMT_MEDIUM, > > And it looked to me that at least parts of it were implemented using > regular code branching. I was thinking that maybe the built-in formats > were defined just using the formatting primitives. But it didn’t look > like that to me.
