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

[Jeff King <peff@peff.net>]

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.
> 
> 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:

-- >8 --
git init repo
cd repo

echo base >base; git add base; git commit -m base
for i in one two three; do
	echo $i >$i
done
git add .
git commit -m master

git checkout -b other HEAD^
echo other >other; git add other; git commit -m other

for i in one two three; do
	echo working-tree >$i
done

git pull . master
-- 8< --

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