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. Le lun. 17 déc. 2018 à 14:37, Duy Nguyen <pclouds@xxxxxxxxx> a écrit : > > On Mon, Dec 17, 2018 at 6:17 PM Elijah Newren <newren@xxxxxxxxx> wrote: > > > > On Mon, Dec 17, 2018 at 8:26 AM Duy Nguyen <pclouds@xxxxxxxxx> wrote: > > > > > > On Mon, Dec 17, 2018 at 2:11 PM Mark Kharitonov > > > <mark.kharitonov@xxxxxxxxx> wrote: > > > > > > > > Hi, > > > > I have asked this question on SO > > > > (https://stackoverflow.com/questions/53679167/can-git-tell-me-which-uncommitted-files-clash-with-the-incoming-changes) > > > > and usually there are tons of responses on Git questions, but not on > > > > this one. > > > > > > > > Allow me to quote it now. > > > > > > > > Please, observe: > > > > > > > > C:\Dayforce\test [master ↓2 +0 ~2 -0 !]> git pull > > > > error: Your local changes to the following files would be > > > > overwritten by merge: > > > > 2.txt > > > > Please commit your changes or stash them before you merge. > > > > Aborting > > > > Updating 2dc8bd0..ea343f8 > > > > C:\Dayforce\test [master ↓2 +0 ~2 -0 !]> > > > > > > > > Does git have a command that can tell me which uncommitted files cause > > > > the this error? I can see them displayed by git pull, but I really do > > > > not want to parse git pull output. > > > > > > Assume that you have done "git fetch origin" (or whatever master's > > > upstream is). Do > > > > > > git diff --name-only HEAD origin/master > > > > > > You get the list of files that will need to be updated. Do > > > > > > git diff --name-only > > > > Are you assuming that `git diff --cached --name-only` is empty? If it > > isn't, that alone will trigger a failure (unless using an esoteric > > merge strategy or an older version of git), so this assumption is > > fairly reasonable to make. But it may be worth being explicit about > > for external readers. > > Actually I think Jeff's suggestion may be better since he compares > worktree with HEAD and should catch everything. > > > > to get the list of files that have local changes. If this list shares > > > some paths with the first list, these paths will very likely cause > > > "git pull" to abort. > > > > > > For a better check, I think you need to do "git read-tree -m" by > > > yourself (to a temporary index file with --index-output) then you can > > > examine that file and determine what file has changed compared to HEAD > > > (and if the same file has local changes, git-pull will be aborted). > > > You may need to read more in read-tree man page. > > > > > > Ideally though, git-read-tree should be able to tell what paths are > > > updated in "--dry-run -u" mode. But I don't think it's supported yet. > > > > merge-recursive currently uses unpack_trees to do this "files would be > > overwritten by merge" checking, so the suggestion of read-tree (which > > also uses unpack_trees) makes sense. BUT ... the error checking in > > unpack_trees has both false positives and false negatives due to not > > understanding renames, and it is somewhat of a nightmarish mess. See > > [1] for details. Further, I think it warns in cases that shouldn't be > > needed (both sides of history modified the same file, with the > > modifications on HEAD's side being a superset of the changes on the > > other side, in such a way that 3-way content merge happens to match > > what is in HEAD already). So, while the suggestions made so far give > > some useful approximations, it's an approximation that will get worse > > over time. > > Ah.. dang. I guess we need "git merge --dry-run" then :) > > > I don't have a better approximation to provide at this > > time, though. > > > > > > Elijah > > > > [1] https://public-inbox.org/git/20171124195901.2581-1-newren@xxxxxxxxx/ > > , starting at "Note that unpack_trees() doesn't understand renames" > > and running until "4-way merges simply cause the complexity to > > increase with every new capability." > > > > -- > Duy -- Be well and prosper. ============================== "There are two kinds of people.Those whose guns are loaded and those who dig." ("The good, the bad and the ugly") So let us drink for our guns always be loaded.
