Re: Why git silently replaces untracked files?

From: Jeff King <peff@peff.net>
Date: Mar 25, 2011, 18:06 UTC
Message-ID: <20110325180644.GA30838@sigill.intra.peff.net>
In-Reply-To: <1301075628970-6208585.post@n2.nabble.com>

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

Show 22 quoted lines

> > 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 &quot;$orig_head&quot;
> >  then
> >  	git update-ref -m &quot;initial pull&quot; HEAD $merge_head
> > &quot;$curr_head&quot; &amp;&amp;
> > -	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 &quot;-m&quot;. 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