Roger Light <roger@xxxxxxxxxx> writes:
> 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.
