Re: Commit dates on conflict markers

From: Jeff King <peff@peff.net>
Date: Sep 12, 2023, 08:57 UTC
Message-ID: <20230912085720.GE1630538@coredump.intra.peff.net>
In-Reply-To: <xmqq8r9cs2x1.fsf@gitster.g>

On Mon, Sep 11, 2023 at 04:31:06PM -0700, Junio C Hamano wrote:

Show 5 quoted lines

> 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