Jeff King <peff@xxxxxxxx> wrote: > > ... > > 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? Exactly. > 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. Thanks a lot for this, I will try it. > 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. > That is exactly my workflow and I am perfectly happy with that. The problem is that I am putting git in the hands of svnites and sometimes I have to address some usability issues like these. It is another issue, but I feel that the 'dirty working directory' is one of the major usability hurdles for people migrating from svn and CVS (a git pull --merge-using-stash could address it, maybe). -- aghiles -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html