Thread (10 messages) flat view 10 messages, 5 authors, 2018-12-18

Re: Can git tell me which uncommitted files clash with the incoming changes?

From: Elijah Newren <hidden>
Date: 2018-12-18 15:51:53

On Tue, Dec 18, 2018 at 5:14 AM Jeff King [off-list ref] wrote:
On Mon, Dec 17, 2018 at 05:50:31PM -0500, Mark Kharitonov wrote:
quoted
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
parseable.

All that said...
quoted
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:
        one
        three
        two
  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?

-Peff
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??)
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help