Re: Why git silently replaces untracked files?

["igor.mikushkin" <igor.mikushkin@gmail.com>]

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.