From: Aghiles <aghilesk@gmail.com>
Date: Fri, 09 Apr 2010 19:33:35 GMT
Subject: Re: git pull suggestion
Message-ID: <i2y3abd05a91004091233nc11ee5f8m4f40e7451e02518a@mail.gmail.com>
In-Reply-To: <20100409034911.GA4020@coredump.intra.peff.net>

Jeff King <peff@peff.net> 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