Re: Why git silently replaces untracked files?

[Jeff King <peff@peff.net>]

On Fri, Mar 25, 2011 at 10:53:48AM -0700, igor.mikushkin wrote:

> > 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.

It will fail with "untracked file 'test' would be overwritten..."; it's
just that --reset turns off the safety features of read-tree, which I
don't see a point in doing.

While looking at this, I also noticed that "git merge" behaves in a
funny way on this case. So I came up with this patch series:

  [1/4]: t7607: mark known breakage in test 11 as fixed
  [2/4]: t7607: clean up stray untracked file
  [3/4]: merge: merge unborn index before setting ref
  [4/4]: pull: do not clobber untracked files on initial pull

-Peff