Re: Can git tell me which uncommitted files clash with the incoming changes?

On Mon, Dec 17, 2018 at 6:17 PM Elijah Newren [off-list ref] wrote:

On Mon, Dec 17, 2018 at 8:26 AM Duy Nguyen [off-list ref] wrote:

quoted

On Mon, Dec 17, 2018 at 2:11 PM Mark Kharitonov
[off-list ref] wrote:

quoted

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.

quoted

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@gmail.com/
, 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