Re: [PATCHv6 4/4] status: better advices when splitting a commit (during rebase -i)
- From
Phil Hord <phil.hord@gmail.com>
- Date
- Jun 4, 2012, 15:35 UTC
- Message-ID
- <CABURp0pD-QuAsDAJXnQXn3sTLb__maw0Mc30PHhduTZ9YOB1FQ@mail.gmail.com>
- In-Reply-To
- <1338748217-16440-4-git-send-email-Lucien.Kong@ensimag.imag.fr>
On Sun, Jun 3, 2012 at 2:30 PM, Kong Lucien <Lucien.Kong@ensimag.imag.fr> wrote:
Show 19 quoted lines
> 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 <Lucien.Kong@ensimag.imag.fr> > Signed-off-by: Duperray Valentin <Valentin.Duperray@ensimag.imag.fr> > Signed-off-by: Jonas Franck <Franck.Jonas@ensimag.imag.fr> > Signed-off-by: Nguy Thomas <Thomas.Nguy@ensimag.imag.fr> > Signed-off-by: Nguyen Huynh Khoi Nguyen <Huynh-Khoi-Nguyen.Nguyen@ensimag.imag.fr> > Signed-off-by: Moy Matthieu <Matthieu.Moy@grenoble-inp.fr> > --- > 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.
Just a note to consider, in case this decision was made arbitrarily.
Thanks for looking after these kinds of corner cases.
Phil