Re: git pull suggestion

[Jeff King <peff@peff.net>]

On Thu, Apr 08, 2010 at 11:06:42PM -0400, Aghiles wrote:

> Kind of ! 'git status' will effectively tell you what files are
> modified but not in the index. The problem is that there is no way to
> know what files are in potential conflict with what is coming from
> 'git pull'. So basically, you can have as many dirty files as you want
> in your working directory as long as they are not conflicting with
> what's coming.
> If dirty files are in conflict, then 'git pull' will complain, but
> slowly ... :)

I think I get what you are talking about now. Consider the following
example script, and let me know if it illustrates your problem:

  # define some handy functions
  content() {
    echo 1 $1 >file1
    echo 2 $1 >file2
  }
  commit() {
    git add file1 file2
    git commit -m "$1"
  }

  # make a new repo
  mkdir repo && cd repo && git init

  # make two diverged branches
  content one; commit one
  git checkout -b other
  content two; commit two
  git checkout master
  content three; commit three

  # now give us dirty working tree state on both files
  content four

  # and try to merge
  git merge other

I get:

  $ git merge other
  error: Your local changes to 'file1' would be overwritten by merge. Aborting.
  Please, commit your changes or stash them before you can merge.

But that's not the whole story. Once you fix that, you will see that
your local changes to 'file2' would be overwritten by the merge:

  $ git commit -m "commit file1" file1
  $ git merge other
  error: Your local changes to 'file2' would be overwritten by merge. Aborting.
  Please, commit your changes or stash them before you can merge.

And so on.

Notice that I didn't use "pull", but pull should invoke git-merge after
fetching from the remote. I assume this is the same message you are
talking about?

I agree it would be nicer if, on the error case, we kept going through
the index to find all of the other error cases, and printed them all.
The code for that is a bit tricky, though, as the unpack-trees merging
code which produces that message is a callback, and only sees one cache
entry at a time.

It is possible to manually get the answer you want, or close to it. You
are looking for the intersection of files modified by you and files
modified by the upstream. So:

  # unique list of modified working tree files and index entries
  $ (git diff-files --name-only;
     git diff-index --name-only HEAD
    ) | sort -u >us
  # files that will be changing as part of merge
  $ git diff-tree --name-only $HEAD_TO_MERGE_FROM | sort >them
  $ comm -12 us them

where $HEAD_TO_MERGE_FROM in my example would be "other", but in the
case of a pull, would probably be FETCH_HEAD.

It isn't 100% accurate, as there are some special cases that the merging
code handles (e.g., I think if the remote changed a file and we have the
same uncommitted change in our working tree, we may still allow that.
There are probably others, too). But it should give a general idea of
what is in conflict.

In practice, I have never actually wanted to this. The workflow goes
something like:

  (1) Run git merge foo (or git pull)

  (2) Oops, I have cruft in my working tree. What was it? Run git
      status.

  (3a) Oh, that cruft should have been committed. Make a commit (or
       commits). Go to (1), possibly still with some changes in
       the working tree.

       or

  (3b) Oh, that cruft is some change I want to carry forward in the
       working directory. Run git stash, repeat the pull, fix any
       merge conflicts, and then git stash apply.

So it doesn't really matter to me if there is 1 conflicting file or 100.
In most cases, the commits in (3a) will clean up all of it in one go.
Otherwise, I'll just stash it all and come back to it.

-Peff