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
