Re: is it a bug that git status show the in-progress 'edit' in an interactive rebase as 'done'?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Feb 6, 2024 at 2:32 AM Oswald Buddenhagen
<oswald.buddenhagen@xxxxxx> wrote:
>
> On Tue, Feb 06, 2024 at 01:02:43AM -0900, Britton Kerin wrote:
> >>Last command done (1 command done):
> >>   edit 71b73de914 message for first commit
> >>...
> >>You are currently editing a commit while rebasing branch
> >>...
> >
> >This seems wrong, because until git rebase --continue has been done
> >the edit operation for the first commit is *ongoing* and it would be
> >much clearer for the output of status to accurately say so.
> >
> it makes a lot of more sense when you decompose 'edit' into 'pick'
> followed by 'break', which it essentially is. so from git's perspective,
> the command really _is_ already done. note that in this state, you can

well viewed this way the pick may be done but not the implicit break

> do all kinds of crazy things - including adding new commits (possibly by
> cherry-picking them) and even dropping already rewritten commits (using
> a hard reset). so in a way, the message above is even a bit too
> suggestive.

Yes.  I'd handle this by changing the description of edit offered in
the comments in the todo to better reflect the possibilities.  The
hints that git rebase -i  (or --continue I guess) gives when it hits
the edit commit also don't reflect all the possibilities very well.

Britton





[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux