From mboxrd@z Thu Jan 1 00:00:00 1970 From: "igor.mikushkin" Subject: Re: Why git silently replaces untracked files? Date: Fri, 25 Mar 2011 10:53:48 -0700 (PDT) Message-ID: <1301075628970-6208585.post@n2.nabble.com> References: <1301064754576-6207950.post@n2.nabble.com> <20110325165811.GB25851@sigill.intra.peff.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: git@vger.kernel.org X-From: git-owner@vger.kernel.org Fri Mar 25 18:53:54 2011 Return-path: Envelope-to: gcvg-git-2@lo.gmane.org Received: from vger.kernel.org ([209.132.180.67]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Q3BCs-0003y9-1G for gcvg-git-2@lo.gmane.org; Fri, 25 Mar 2011 18:53:54 +0100 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754555Ab1CYRxt (ORCPT ); Fri, 25 Mar 2011 13:53:49 -0400 Received: from sam.nabble.com ([216.139.236.26]:40019 "EHLO sam.nabble.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754525Ab1CYRxt (ORCPT ); Fri, 25 Mar 2011 13:53:49 -0400 Received: from jim.nabble.com ([192.168.236.80]) by sam.nabble.com with esmtp (Exim 4.69) (envelope-from ) id 1Q3BCm-0005Nd-VU for git@vger.kernel.org; Fri, 25 Mar 2011 10:53:48 -0700 In-Reply-To: <20110325165811.GB25851@sigill.intra.peff.net> Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: 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.