Thread (29 messages) 29 messages, 6 authors, 2h ago

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

From: Junio C Hamano <hidden>
Date: 2026-09-29 01:56:15

Jeff King [off-list ref] writes:
On Mon, Sep 28, 2026 at 04:41:54PM -0400, Julia Evans wrote:
quoted
quoted
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'".
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help