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

[Junio C Hamano <gitster@pobox.com>]

Jeff King <peff@peff.net> writes:

> 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
> ...
> If you do want to look ahead, I think "next" or "jch" is often a more
> useful target.

As Julia is working mostly on documentation modernization, what you
and I view as an advantage may not be as relevant to her as it is to
those who work with code.

Regardless of which "more advanced" branch you pick to cross-check
with other topics in flight, I do not think you want to apply your
patches _on_ that branch.  Rather, apply your patches on a stable
base (e.g., a release tag, or the tip of then-current 'master'), and
make a trial merge of your topic branch into the "more advanced"
target branch.

Even without building, you may find merge conflicts, through which
you will learn what other contributors are working on in the same
area.  You may run git log --merge --left-right -p right there while
you have conflicts, and may even learn that a helper function or two
your topic would benefit from have already been written in their
topics.  Even when there is no textual conflict, 'make' (just
building alone) may reveal that an API function your topic depends
on has been updated by another topic in flight, and the result does
not even build as a consequence.  Again, you learn about the topics
by others that may be very relevant to you.

If you are working in a fairly isolated area, none of the above may
happen, of course.

> 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).

These days my personal rule is to make sure that the topics must be
in 'jch' before it is marked with "Will merge to 'next'".