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

From: Jeff King <peff@peff.net>
Date: Dec 18, 2018, 13:14 UTC
Message-ID: <20181218131429.GE30471@sigill.intra.peff.net>
In-Reply-To: <CAG2YSPy85YtAv6m5WR4ZrsZ4TRzgcyrC4DNZnOONtFD6MsH=YQ@mail.gmail.com>

On Mon, Dec 17, 2018 at 05:50:31PM -0500, Mark Kharitonov wrote:

Show 17 quoted lines

> 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