Re: git 1.4.0 usability problem

Jeff Garzik [off-list ref] writes:

Here's a real world example of the 1.4.0 change breaking a merge:

("netdev-2.6" == local clone of kernel.org/...jgarzik/netdev-2.6.git)
[jgarzik@pretzel netdev-2.6]$ git branch
  ALL
  e100-sbit
* master
  upstream
  upstream-linus

[jgarzik@pretzel netdev-2.6]$ git pull /spare/repo/linux-2.6
...
Updating from 427abfa28afedffadfca9dd8b067eb6d36bac53f to
25f42b6af09e34c3f92107b36b5aa6edc2fdba2f
fatal: Untracked working tree file 'drivers/net/myri10ge/Makefile'
would be overwritten by merge.

EXPLANATION:

* drivers/net/myri10ge/Makefile exists in latest Linus kernel tree,
stored locally in /spare/repo/linux-2.6.
* drivers/net/myri10ge/Makefile exists in netdev-2.6#upstream and
netdev-2.6#upstream-linus branches.
* drivers/net/myri10ge/Makefile does not exist in current branch,
netdev-2.6#master.

Requesting one more bit of explanation.

When you did this pull, you were on your "master" branch.  Whose
HEAD does not have the myri10ge/Makefile in its tree.  And you
did not have that path in the index either (otherwise it would
not have said "untracked working tree file").  Did you have that
file in your working tree?  And if so how/why?

If you did something like this before ending up in your "master"
branch, I think you would have such a file:

	$ git branch ;# you were in upstream-linus branch
          ALL
          e100-sbit
          master
          upstream
        * upstream-linus
        $ git diff      ;# and were up-to-date -- no output nor
        $ git diff HEAD ;# local changes
        $ git checkout -f master ;# but you switched to master with -f

With "checkout -f", your local changes to files that appear in
the "master" branch will be overwritten, but the files that are
supposed to disappear because you are switching out of the
current branch (e.g. myri10ge/Makefile) are left behind.

It probably would make sense to change "checkout -f" so that it
removes such files from your working tree to support this
particular usage.  We kept saying "with -f local dirty state
will be gone", but "checkout -f" does not do as thorough job as
"reset --hard".  Changing "checkout -f next-branch" to do the
moral equivalent of "reset --hard HEAD && checkout next-branch"
would solve this problem, and I do not think changing it that
way would not have any negative impact.

I suspect this patch would do exactly that...

diff --git a/git-checkout.sh b/git-checkout.sh
index 564117f..193f6c5 100755
--- a/git-checkout.sh
+++ b/git-checkout.sh

@@ -137,7 +137,7 @@ # what we already had
 
 if [ "$force" ]
 then
-    git-read-tree --reset $new &&
+    git-read-tree --reset -u $new &&
 	git-checkout-index -q -f -u -a
 else
     git-update-index --refresh >/dev/null