Re: [PATCH 0/7] [doc] Add new page on merge conflicts

[Jeff King <peff@peff.net>]

On Mon, Sep 28, 2026 at 04:41:54PM -0400, Julia Evans wrote:

> > I think that is giving us a good signal, though. The guide should be
> > mentioned in command-list.txt, so that it is linked from git(1).
> 
> Thanks, will fix this (and will move the conflict-marker-size change).
> 
> Should I be trying to apply my patches to `seen` before submitting them?

In general, no, you don't have to. In this case it turned up useful
information for changing your series, but that's rare. The more likely
outcome is that there's nothing to be changed in your series, but
there's a conflict (either textual or semantic) between two topics that
has to be resolved by the maintainer.

Of course if you know about that conflict and can warn people in the
cover letter (and sometimes even suggest a resolution, or work around it
somehow), that can distribute some of the load. But I don't know that I
would recommend for everyone to manually merge their topic to 'seen' in
the hopes that it finds something useful. It usually won't.

But depending on the rest of your workflow, you might get advanced
warning of such interactions for free-ish. For example, I merge all of
my personal topics every day to the "jch" branch to build the version of
Git that I run day-to-day. So I learn about those interactions early
when my build fails, or my personal copy breaks. ;) But that's not
something I'd expect most people to do.

If you do want to look ahead, I think "next" or "jch" is often a more
useful target. A topic on the seen branch just means it was seen by the
maintainer, and might not even pass all of the tests. Whereas "next" is
fairly stable, and "jch" is (I believe) what Junio runs day to day (so a
subset of "seen" that seems pretty stable).

-Peff