Re: [BUG?] rebase -i: edit versus unmerged changes

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 24, 2013, 05:13 UTC
Message-ID: <7vhak14bys.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CALkWK0nspPEaA3BLjgV6Qv2UgXRbDft1d6SmRCiVNJoxpqLFwg@mail.gmail.com>

Ramkumar Ramachandra <artagnon@gmail.com> writes:

Show 9 quoted lines

> Junio C Hamano wrote:
>
>> FWIW, I am not convinced yet why we would even want "git continue"
>> in the first place, so I won't be the one who would be suggesting a
>> migration path.
>
> Okay, I'm confused now.  You were the one who suggested a unified "git
> continue" in the first place, if my memory serves me right.  Why are
> you doubting it now?

AFAIR, the only thing I said about "continue" was that in a more rational future where many "git frotz" commands that can stop and ask the user to help exist, after the user helps the command by creating the desired outcome in the index, the way the user signals that she is done helping would be "git frotz --continue", and the "After helping 'git merge', conclude it with 'git commit'" would be an odd-man-out, and adding 'git merge --continue' may not be a bad idea to make things more consistent. Originally the way to help "am" (with or without "-3") was to say "am --resolved", but that has long been fixed to also take "am --continue".

So if you are adding "git merge --continue", that would be fine by me, but I never said "git continue" subcommand would make any sense at all.