Re: Any interest in 'git merge --continue' as a command

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

 



On Fri, Dec 09, 2016 at 11:16:52AM -0800, Junio C Hamano wrote:

> > It seems like that would be in line with 35d2fffdb (Provide 'git merge
> > --abort' as a synonym to 'git reset --merge', 2010-11-09), whose stated
> > goal was providing consistency with other multi-command operations.
> >
> > I assume it would _just_ run a vanilla "git commit", and not try to do
> > any trickery with updating the index (which could be disastrous).
> 
> If we were to have "merge --continue", I agree that it would be the
> logical implementation.
> 
> There is nothing to "continue" in a stopped merge where Git asked
> for help from the user, and because of that, I view the final "git
> commit" as "concluding the merge", not "continuing".  "continue"
> makes quite a lot of sense with rebase and cherry-pick A..B that
> stopped; it concludes the current step and let it continue to
> process the remainder.  So from that point of view, it somewhat
> feels strange to call it "merge --continue", but it probably is just
> me.

No, I think your reasoning makes sense. But I also think we've already
choosen to have "--continue" mean "conclude the current, and continue if
there is anything left" in other contexts (e.g., a single-item
cherry-pick). It's more vague, but I think it keeps the user's mental
model simpler if we provide a standard set of options for multi-step
commands (e.g., always "--continue/--abort/--skip", though there are
some like merge that omit "--skip" if it does not make sense).

-Peff



[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]