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
