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

[Duy Nguyen <pclouds@gmail.com>]

On Mon, Dec 17, 2018 at 6:17 PM Elijah Newren <newren@gmail.com> wrote:
>
> On Mon, Dec 17, 2018 at 8:26 AM Duy Nguyen <pclouds@gmail.com> wrote:
> >
> > On Mon, Dec 17, 2018 at 2:11 PM Mark Kharitonov
> > <mark.kharitonov@gmail.com> 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@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