From: Julia Evans <julia@jvns.ca>
Date: Thu, 01 Oct 2026 12:10:11 GMT
Subject: Re: [PATCH 1/7] [doc] Add new gitmergeconflicts man page
Message-ID: <86a7df9d-362a-4530-82db-44ef7500fd10@app.fastmail.com>
In-Reply-To: <ar3sGzEknG2_Un_E@pks.im>


> +FRUITS = [
> +    "apple",
> +<<<<<<< HEAD: abcdefg (fruits: add apple, 2026-10-01)
> +    "cherry",
> +=======
> +    "banana",
> +>>>>>>> add-fruit: 12345678 (fruits: add banana, 2024-02-03)
>
> That format would have a bunch of advantages:
>
>   - We don't have to teach users about special refs like MERGE_HEAD to
>     let them figure out how to access each of the commits.
>
>   - It gives a bit more context about what each specific side does, at
>     least if you have good commit messages.
>
>   - It also gives a sense of timing because we include dates, and that
>     may help in some situations to figure out what's what.

This is so cool, I love the idea of including the dates and the commit
messages!!! I think this would be very helpful for the reasons you say. 

Though re "We don't have to teach users about special refs
like MERGE_HEAD": I think that users today could run`git show HEAD`
or `git show add-fruit` to see the commits on each side? I've never
used MERGE_HEAD though so maybe I'm misunderstanding what
it does. I think adding the commit ID makes it clearer too.

I just ran downstairs to show my partner this example at 8am
because I was so excited about it :) (he liked it too)