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
