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

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 29, 2026, 01:56 UTC
Message-ID: <xmqqse2skegz.fsf@gitster.g>
In-Reply-To: <20260929013233.GA1089022@coredump.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 13 quoted lines

> 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'".