Re: Any interest in 'git merge --continue' as a command
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
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
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
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
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
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
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
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