Re: [PATCH 09/12] merge-tree: provide a list of which files have conflicts
- From
Johannes Schindelin <johannes.schindelin@gmx.de>
- Date
- Feb 21, 2022, 09:31 UTC
- Message-ID
- <nycvar.QRO.7.76.6.2202211029220.26495@tvgsbejvaqbjf.bet>
- In-Reply-To
- <CABPp-BFyaakDSjHULpBRPQqq_jz2keyufHo1MjNS6dHQNR+JLQ@mail.gmail.com>
Hi Elijah,
[reinstating the Cc: list]
On Sat, 12 Feb 2022, Elijah Newren wrote:
Show 40 quoted lines
> On Fri, Feb 4, 2022 at 3:12 PM Johannes Schindelin > <Johannes.Schindelin@gmx.de> wrote: > > > > On Fri, 28 Jan 2022, Elijah Newren wrote: > > > > > On Fri, Jan 28, 2022 at 8:57 AM Johannes Schindelin > > > <Johannes.Schindelin@gmx.de> wrote: > > > > > > > > Hi Elijah, > > > > > > > > On Sat, 22 Jan 2022, Elijah Newren via GitGitGadget wrote: > > > > > > > > > From: Elijah Newren <newren@gmail.com> > > > > > > > > [...] > > > > > diff --git a/Documentation/git-merge-tree.txt b/Documentation/git-merge-tree.txt > > > > > index fd7a867de60..041a4ac2785 100644 > > > > > --- a/Documentation/git-merge-tree.txt > > > > > +++ b/Documentation/git-merge-tree.txt > > > > > @@ -58,6 +58,7 @@ simply one line: > > > > > Whereas for a conflicted merge, the output is by default of the form: > > > > > > > > > > <OID of toplevel tree> > > > > > + <Conflicted file list> > > > > > <Informational messages> > > > > > > > > To distinguish between the list of conflicted files and the informational > > > > messages, I think it would be good to insert an empty line, as a > > > > separator, like. > > > > > > Yes, I agree; that's why I did so. :-) > > > > My concern was that I did not see this empty line reflected in the quoted > > diff. I would have expected an empty line between the `<Conflicted [...]>` > > and the `<Informational [...]>` line. > > As stated later in the same email, the newline is only printed if the > <Informational messages> section is printed. As such, it's part of > the <Informational messages> section and listing it between the > sections could be misleading.
Thank you for the clarification. I still think that it might cause confusion in the documentation not to see the explicit newline, quite possible when _I_ re-read this in six months from now. But then, if `-z` is in effect, it won't be an explicit newline, it will be a NUL instead.
In short: I am fine with leaving this as-is, it might actually reduce even _my_ confusion to the minimum possible.
Thanks, Dscho