On Fri, Mar 25, 2011 at 07:52:34AM -0700, igor.mikushkin wrote: > Why git silently replaces untracked files? > > # mkdir test.git > # mkdir 1 > # mkdir 2 > # echo 1 > 1/test > # echo 2 > 2/test > # cd test.git > # git init --bare > # cd .. > # git clone test.git > # cp -r test/.git 1 > # cp -r test/.git 2 > # cd 1 > # git add test > # git commit -am 1 > # git push origin master > # cd ../2 > # git pull > # cat test > 1 > > In my opinion it is wrong behavior. > I've just lost important file due to it. > > Should not "git pull" fail here? Ick, definitely it's wrong behavior. The culprit seems to be a special code path for the initial pull which doesn't merge at all, but calls read-tree --reset. It should probably be: diff --git a/git-pull.sh b/git-pull.sh index a3159c3..fb9e2df 100755 --- a/git-pull.sh +++ b/git-pull.sh @@ -253,7 +253,7 @@ esac if test -z "$orig_head" then git update-ref -m "initial pull" HEAD $merge_head "$curr_head" && - git read-tree --reset -u HEAD || exit 1 + git read-tree -m -u HEAD || exit 1 exit fi Though I don't know if there are any cases where the --reset would be beneficial over "-m". I couldn't think of any. -Peff -- 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