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