Jeff King wrote: > > 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. > Thanks Jeff, My opinion is that you are right and merging is best here (Though just fail would be probably OK either). Love one line fixes. Igor -- View this message in context: http://git.661346.n2.nabble.com/Why-git-silently-replaces-untracked-files-tp6207950p6208585.html Sent from the git mailing list archive at Nabble.com. -- 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