From mboxrd@z Thu Jan 1 00:00:00 1970 From: John Nowak Subject: reproducible unexpected behavior for 'git reset' Date: Sun, 10 Jul 2011 18:30:31 -0400 Message-ID: <75BBC138-2BD7-41F9-9D84-CEFF23CDC235@johnnowak.com> Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8BIT To: git@vger.kernel.org X-From: git-owner@vger.kernel.org Mon Jul 11 00:31:04 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 1Qg2Wl-0000dS-M1 for gcvg-git-2@lo.gmane.org; Mon, 11 Jul 2011 00:31:04 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756744Ab1GJWai (ORCPT ); Sun, 10 Jul 2011 18:30:38 -0400 Received: from birch.site5.com ([174.132.116.226]:43357 "EHLO birch.site5.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753791Ab1GJWah convert rfc822-to-8bit (ORCPT ); Sun, 10 Jul 2011 18:30:37 -0400 X-Greylist: delayed 1665 seconds by postgrey-1.27 at vger.kernel.org; Sun, 10 Jul 2011 18:30:37 EDT Received: from user-387hdgh.cable.mindspring.com ([208.120.182.17] helo=[192.168.1.200]) by birch.site5.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1Qg2WJ-00046l-0Q for git@vger.kernel.org; Sun, 10 Jul 2011 17:30:35 -0500 X-Mailer: Apple Mail (2.1084) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - birch.site5.com X-AntiAbuse: Original Domain - vger.kernel.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - johnnowak.com X-Source: X-Source-Args: X-Source-Dir: Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: (Apologies if you receive this twice. I sent the first copy before confirming my list subscription and I'm not sure if it went through.) I am able to reproduce a scenario where, after a 'commit' and a 'stash pop' that results in a merge conflict, I need to 'reset' a file twice in order to get the index back to HEAD. It appears that the first 'reset' sets the index to the merge base version instead of HEAD which was, for me, rather unexpected. I encountered this on 1.7.4 but others have reproduced it on the latest master. If this behavior is documented, I cannot find it. A transcript to reproduce this oddity is below; note how the file is partially staged after the first 'reset' and unstaged after the second: --- $ git init Initialized empty Git repository in /Users/jn/test/.git/ $ echo "a" > foo $ git add foo $ git commit -a -m "Initial" [master (root-commit) 5214837] Initial 1 files changed, 1 insertions(+), 0 deletions(-) create mode 100644 foo $ echo "b" >> foo $ git stash Saved working directory and index state WIP on master: 5214837 Initial HEAD is now at 5214837 Initial $ echo "c" >> foo $ git add foo $ git commit -a -m "Added c" [master 69eef48] Added c 1 files changed, 1 insertions(+), 0 deletions(-) $ git stash pop Auto-merging foo CONFLICT (content): Merge conflict in foo $ git status # On branch master # Unmerged paths: # (use "git reset HEAD ..." to unstage) # (use "git add/rm ..." as appropriate to mark resolution) # # both modified: foo # no changes added to commit (use "git add" and/or "git commit -a") $ git reset foo Unstaged changes after reset: M foo $ git status # On branch master # Changes to be committed: # (use "git reset HEAD ..." to unstage) # # modified: foo # # Changes not staged for commit: # (use "git add ..." to update what will be committed) # (use "git checkout -- ..." to discard changes in working directory) # # modified: foo # $ git reset foo Unstaged changes after reset: M foo $ git status # On branch master # Changes not staged for commit: # (use "git add ..." to update what will be committed) # (use "git checkout -- ..." to discard changes in working directory) # # modified: foo # no changes added to commit (use "git add" and/or "git commit -a")