From: konglu@minatec.inpg.fr Date: Tue, 05 Jun 2012 09:13:07 GMT Subject: Re: [PATCHv6 4/4] status: better advices when splitting a commit (during rebase -i) Message-ID: <20120605111307.Horde.-xsEEHwdC4BPzc2jJ-GgdjA@webmail.minatec.grenoble-inp.fr> In-Reply-To: Phil Hord a écrit : > On Sun, Jun 3, 2012 at 2:30 PM, Kong Lucien > wrote: >> Add new informative help messages at the output of 'git status' when >> the user is splitting a commit. The code figures this state by >> comparing the contents of the following files in the .git/ directory: >>          - HEAD >>          - ORIG_HEAD >>          - rebase-merge/amend >>          - rebase-merge/orig-head >> >> Signed-off-by: Kong Lucien >> Signed-off-by: Duperray Valentin >> Signed-off-by: Jonas Franck >> Signed-off-by: Nguy Thomas >> Signed-off-by: Nguyen Huynh Khoi Nguyen >> >> Signed-off-by: Moy Matthieu >> --- >> The second test added by this patch fails because the case in which >> the user amend the last commit through rebase -i is not taken care of. >> We infer that the user would directly run "git commit --amend" instead >> of amending it with a rebase -i. > > > Maybe this is safe and logical for most workflows, or maybe this is a > convenience that makes this patch possible (I did not read the patch > yet). But I know that I sometimes use rebase-i instead of > commit--amend because I did not realize the patch I am fixing is the > most recent one until after continuing, or because the patch I am > amending was moved into the most-recent position during the rebase-i > itself. Right, This case has to be taken care of. It will need some work as it's quite difficult to distinguish the current state after doing a reset HEAD^ or doing a commit --amend when the rebase-merge/amend is set on the last commit.