On Mon, Sep 11, 2023 at 04:31:06PM -0700, Junio C Hamano wrote:
> A change that only shows the commit date without allowing end user
> configuration will *not* be worth doing, but allowing them to use
> placeholders like '%h %s' in "git log --format='%h %s'" (check
> pretty.c for the catalog) would be a good exercise; it should not
> take somebody with an ultra-deep knowledge of how the code works.
FWIW, I had the same thought. But I wasn't quite sure where we even set
these strings, so here are a few thoughts for anybody who wants to work
on it:
- the relevant strings are passed in to ll_merge(); you can grep for
callers and see that there are a number of strings which end up here
(based on what info we actually have).
The most interesting one to start with is probably the call in
merge_3way() of merge-ort.c.
- there we have three object_ids, "o", "a", and "b" representing the
three sides. But these are just blobs. We have strings "ancestor",
"branch1", and "branch2" in merge_options, but we would probably not
want to re-resolve those names. So probably some extra fields need
to go into merge_options.
- I'm not sure if each of those endpoints is always a commit. For a
regular merge, they would be. But in a recursive merge, we'd
sometimes create an intermediate virtual tree. So we'd need to
handle the case that there is no commit (and either fall back to a
more vanilla string, or make a fake commit with reasonable details).
- The current labels are based on the "original" ref names (which I
think are really "what was handed to merge"; so it might be
"master~13" etc) along with the blob path (if it is not the same for
both endpoints). So you'd want more than just passing the format
string to format_commit_message(). You would want an extra
placeholder to represent those values (either ref and pathname
individually, or possibly a single placeholder for "ref and maybe
pathname if it's interesting").
The least-bad way to do that is perhaps to expand the format twice:
once for the special placeholder (quoting any "%" found in the
filename, etc), and then feeding the whole result to the
pretty-print formatter.
I was hoping this might be only a few-line change, but I actually think
it's a bit more complicated than that. But still maybe not _too_ bad.
-Peff
