Re: Can git tell me which uncommitted files clash with the incoming changes?
- Date: Tue, 18 Dec 2018 07:51:39 -0800
- From: Elijah Newren <newren@xxxxxxxxx>
- Subject: Re: Can git tell me which uncommitted files clash with the incoming changes?
On Tue, Dec 18, 2018 at 5:14 AM Jeff King <peff@xxxxxxxx> wrote:
> On Mon, Dec 17, 2018 at 05:50:31PM -0500, Mark Kharitonov wrote:
> > Guys, having git merge --dry-run would be great, but I am OK with git
> > merge for real as long as its output is parseable.
Don't rely on that. merge output has changed occasionally and will
likely change again in the future multiple times. The other solutions
provided by Peff and Duy are much better. If we need to add more
options to provide you with what you need, then that's a route we can
take, but I'll make no guarantees about merge output being stable and
All that said...
> > However, somewhere in between git 2.18 and git 2.20 the output of
> > merge changed and now I do not know how to parse it.
> > it used to be something like that:
> > bla bla bla
> > <tab>file name 1
> > <tab>file name 2
> > ...
> > bla bla bla
> > But now, the files are output in one line and given that some files
> > may have spaces in the name I do not see how this can be parsed. If we
> > could have easily parseable output of merge, it would be enough for
> > me.
> Interesting. I don't see that behavior at all. E.g., running this:
> I see:
> error: The following untracked working tree files would be overwritten by merge:
> Please move or remove them before you merge.
> I wonder if it has to do with Windows.
> If you can reproduce it at will, can you try bisecting between v2.18 and
> v2.20 to see which commit introduced the change?
I see the same as Peff, and I see no changes to
unpack_trees.c:display_error_msgs() since git 2.11 (not even in a
clone of git-for-windows), and as far as I can tell that function is
the place that prints all the files and adds the newlines, so I'm kind
of perplexed how you're seeing things print multiple files on a line.
Bisecting as Peff suggests would help but I'm curious if there's
something special about your setup needed to reproduce and which
changed since you were using 2.18 (e.g. always forcing output through
a pager and having a pager that doesn't understand LF and requires
CRLF to display things correctly??)