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

[Junio C Hamano]

Jeff King  writes:

> 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).

Yup.  I know you know me well enough to know that I didn't mean to
say "oh this one needs to be called differently" ;-)  I just felt
that "--continue" in that context did not sit well.

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

[Jacob Keller]

On Sat, Dec 10, 2016 at 1:00 AM, Jeff King  wrote:
> On Sat, Dec 10, 2016 at 09:49:13PM +1300, Chris Packham wrote:
>
>> > 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.
>>
>> Yeah I did think that --continue wasn't quite the right word. git
>> merge --conclude would probably be the most accurate.
>
> I'd be against giving it a subtly-different name. It's just going to
> frustrate people who cannot remember when to use "--conclude" and when
> it is "--continue". The strength of the proposal, IMHO, is that it
> abstracts the idea of "go on to the next thing or finish" across many
> commands.
>
> -Peff

Agreed. I think "continue" makes sense as the command had to "stop"
the merge so you could give input, and then you tell git to "continue"
which also happens to mean "finish the merge" and yes it may not be
100% accurate, but the point of adding "git merge --continue" is that
it simplifies the mental model between rebase, cherry-pick, and merge,
all of which stop and ask the user to resolve a conflict before
"continue"ing and finalizing that resolution.

Thanks,
Jake

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

[Jeff King]

On Sat, Dec 10, 2016 at 09:49:13PM +1300, Chris Packham wrote:

> > 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.
> 
> Yeah I did think that --continue wasn't quite the right word. git
> merge --conclude would probably be the most accurate.

I'd be against giving it a subtly-different name. It's just going to
frustrate people who cannot remember when to use "--conclude" and when
it is "--continue". The strength of the proposal, IMHO, is that it
abstracts the idea of "go on to the next thing or finish" across many
commands.

-Peff

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

[Jeff King]

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

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

[Chris Packham]

On Sat, Dec 10, 2016 at 8:16 AM, Junio C Hamano  wrote:
> Jeff King  writes:
>
>>> They knew about git rebase --continue (and git am and git cherry-pick)
>>> but they were unsure how to "continue" a merge (it didn't help that
>>> the advice saying to use 'git commit' was scrolling off the top of the
>>> terminal). I know that using 'git commit' has been the standard way to
>>> complete a merge but given other commands have a --continue should
>>> merge have it as well?
>>
>> 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.
>

Yeah I did think that --continue wasn't quite the right word. git
merge --conclude would probably be the most accurate.

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

[Junio C Hamano]

Jeff King  writes:

>> They knew about git rebase --continue (and git am and git cherry-pick)
>> but they were unsure how to "continue" a merge (it didn't help that
>> the advice saying to use 'git commit' was scrolling off the top of the
>> terminal). I know that using 'git commit' has been the standard way to
>> complete a merge but given other commands have a --continue should
>> merge have it as well?
>
> 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.

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

[Jacob Keller]

On December 9, 2016 1:11:27 AM PST, Jeff King  wrote:
>On Fri, Dec 09, 2016 at 08:57:58PM +1300, Chris Packham wrote:
>
>> I hit this at $dayjob recently.
>> 
>> A developer had got themselves into a confused state when needing to
>> resolve a merge conflict.
>> 
>> They knew about git rebase --continue (and git am and git
>cherry-pick)
>> but they were unsure how to "continue" a merge (it didn't help that
>> the advice saying to use 'git commit' was scrolling off the top of
>the
>> terminal). I know that using 'git commit' has been the standard way
>to
>> complete a merge but given other commands have a --continue should
>> merge have it as well?
>
>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).
>
>-Peff

This makes sense to me.

Thanks,
Jake

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

[Jeff King]

On Fri, Dec 09, 2016 at 08:57:58PM +1300, Chris Packham wrote:

> I hit this at $dayjob recently.
> 
> A developer had got themselves into a confused state when needing to
> resolve a merge conflict.
> 
> They knew about git rebase --continue (and git am and git cherry-pick)
> but they were unsure how to "continue" a merge (it didn't help that
> the advice saying to use 'git commit' was scrolling off the top of the
> terminal). I know that using 'git commit' has been the standard way to
> complete a merge but given other commands have a --continue should
> merge have it as well?

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).

-Peff

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

[Chris Packham]

I hit this at $dayjob recently.

A developer had got themselves into a confused state when needing to
resolve a merge conflict.

They knew about git rebase --continue (and git am and git cherry-pick)
but they were unsure how to "continue" a merge (it didn't help that
the advice saying to use 'git commit' was scrolling off the top of the
terminal). I know that using 'git commit' has been the standard way to
complete a merge but given other commands have a --continue should
merge have it as well?