Re: Commit dates on conflict markers

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 11, 2023, 23:31 UTC
Message-ID: <xmqq8r9cs2x1.fsf@gitster.g>
In-Reply-To: <CAH7zdydYgSf+21GB70=gRhEcupv4e1ix==7LWCeQYgpD-1Rcmw@mail.gmail.com>

Roger Light <roger@atchoo.org> writes:

Show 21 quoted lines

> When I carry out a merge with conflicts, it's not always clear when
> resolving the conflicts which is the correct part of code to use. I
> sometimes use git blame to guide me as to the age of the different
> chunks of code and hence what to choose.
>
> I was wondering if there might be a way to help include that sort of
> information directly into the conflict.
>
> If you had a single line conflict it would be straightforward to
> display by including the date the line was last modified alongside the
> conflict marker:
>
> <<<<<<< HEAD date:yesterday
> print("please")
> ======= date:10 years ago
> print("help")
> >>>>>>> main
>
> With a more realistic change with multiple lines and context from
> different commits, it's not immediately obvious to me that it's
> possible to do in a way that isn't completely horrible.

Our conflict marker lines do get human readable labels but the format used by merge_3way() both in merge-ort and merge-recursive backends is hardcoded to be <branchname> ':' <pathname> and it is sufficient to let you tell which commit involved in the merge and which path in that commit the contents came from.

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.