{"thread":{"id":"10710","subject":"git rebase --skip","startedAt":"2007-11-07T22:21:05Z","lastAt":"2007-11-09T17:20:15Z","messageCount":20,"participants":["Mike Hommey","Johannes Schindelin","Jeff King","Jakub Narebski","Björn Steinbrink","Andreas Ericsson","Daniel Barkalow","Junio C Hamano","J. Bruce Fields"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"58738","messageId":"20071107222105.GA31666@glandium.org","threadId":"10710","inReplyTo":null,"subject":"git rebase --skip","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2007-11-07T22:21:05Z","receivedAt":"2007-11-07T22:21:05Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"Hi,\n\nI use git-rebase quite regularly, and I haven't used git-rebase --skip\nafter a failed merge without first resetting the working tree. I was\nwondering if it wouldn't make sense to automatically do the reset when\nrunning git-rebase --skip.\n\nMike\n"},{"id":"58747","messageId":"Pine.LNX.4.64.0711072244180.4362@racer.site","threadId":"10710","inReplyTo":"20071107222105.GA31666@glandium.org","subject":"Re: git rebase --skip","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-07T22:48:39Z","receivedAt":"2007-11-07T22:48:39Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 7 Nov 2007, Mike Hommey wrote:\n\n> I use git-rebase quite regularly, and I haven't used git-rebase --skip \n> after a failed merge without first resetting the working tree. I was \n> wondering if it wouldn't make sense to automatically do the reset when \n> running git-rebase --skip.\n\nMakes sense to me. The user is already required to pass \"--skip\" to say \n\"scrap this patch\".\n\nFWIW --interactive already has this behaviour since it was added to \n\"official\" git.\n\nCiao,\nDscho\n"},{"id":"58792","messageId":"20071108032308.GA5638@sigill.intra.peff.net","threadId":"10710","inReplyTo":"20071107222105.GA31666@glandium.org","subject":"Re: git rebase --skip","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-11-08T03:23:10Z","receivedAt":"2007-11-08T03:23:10Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Nov 07, 2007 at 11:21:05PM +0100, Mike Hommey wrote:\n\n> I use git-rebase quite regularly, and I haven't used git-rebase --skip\n> after a failed merge without first resetting the working tree. I was\n> wondering if it wouldn't make sense to automatically do the reset when\n> running git-rebase --skip.\n\nI have often been annoyed by this behavior, too, and I can't think of\nany situation where you _wouldn't_ want the reset to happen. But I\nwould be more comfortable hearing confirmation from others that they\ncan't think of such a situation.\n\n-Peff\n"},{"id":"58793","messageId":"fgtvu9$o1r$1@ger.gmane.org","threadId":"10710","inReplyTo":"20071108032308.GA5638@sigill.intra.peff.net","subject":"Re: git rebase --skip","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-11-08T03:31:23Z","receivedAt":"2007-11-08T03:31:23Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jeff King wrote:\n\n> On Wed, Nov 07, 2007 at 11:21:05PM +0100, Mike Hommey wrote:\n> \n>> I use git-rebase quite regularly, and I haven't used git-rebase --skip\n>> after a failed merge without first resetting the working tree. I was\n>> wondering if it wouldn't make sense to automatically do the reset when\n>> running git-rebase --skip.\n> \n> I have often been annoyed by this behavior, too, and I can't think of\n> any situation where you _wouldn't_ want the reset to happen. But I\n> would be more comfortable hearing confirmation from others that they\n> can't think of such a situation.\n\nPerhaps \"git rebase --force-skip\" or \"git rebase --force --skip\"\nwould be the way to fo above...\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"58803","messageId":"1194505386-18156-1-git-send-email-mh@glandium.org","threadId":"10710","inReplyTo":"20071107222105.GA31666@glandium.org","subject":"[PATCH] Do git reset --hard HEAD when using git rebase --skip","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2007-11-08T07:03:06Z","receivedAt":"2007-11-08T07:03:06Z","isPatch":true,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"When you have a merge conflict and want to bypass the commit causing it,\nyou don't want to care about the dirty state of the working tree.\n\nAlso, don't git reset --hard HEAD in the rebase-skip test, so that the\nlack of support for this is detected.\n\nSigned-off-by: Mike Hommey \n---\n git-rebase.sh | 1 +\n t/t3403-rebase-skip.sh | 2 --\n 2 files changed, 1 insertions(+), 2 deletions(-)\n\ndiff --git a/git-rebase.sh b/git-rebase.sh\nindex e3ad7de..8814be9 100755\n--- a/git-rebase.sh\n+++ b/git-rebase.sh\n@@ -158,6 +158,7 @@ do\n \t\texit\n \t\t;;\n \t--skip)\n+\t\tgit reset --hard HEAD || exit $?\n \t\tif test -d \"$dotest\"\n \t\tthen\n \t\t\tgit rerere clear\ndiff --git a/t/t3403-rebase-skip.sh b/t/t3403-rebase-skip.sh\nindex eab053c..becabfc 100755\n--- a/t/t3403-rebase-skip.sh\n+++ b/t/t3403-rebase-skip.sh\n@@ -36,7 +36,6 @@ test_expect_failure 'rebase with git am -3 (default)' '\n '\n \n test_expect_success 'rebase --skip with am -3' '\n-\tgit reset --hard HEAD &&\n \tgit rebase --skip\n \t'\n test_expect_success 'checkout skip-merge' 'git checkout -f skip-merge'\n@@ -44,7 +43,6 @@ test_expect_success 'checkout skip-merge' 'git checkout -f skip-merge'\n test_expect_failure 'rebase with --merge' 'git rebase --merge master'\n \n test_expect_success 'rebase --skip with --merge' '\n-\tgit reset --hard HEAD &&\n \tgit rebase --skip\n \t'\n \n-- \n1.5.3.5\n"},{"id":"58855","messageId":"20071108102412.GA31187@atjola.homenet","threadId":"10710","inReplyTo":"20071108032308.GA5638@sigill.intra.peff.net","subject":"Re: git rebase --skip","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2007-11-08T10:24:12Z","receivedAt":"2007-11-08T10:24:12Z","isPatch":false,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2007.11.07 22:23:10 -0500, Jeff King wrote:\n> On Wed, Nov 07, 2007 at 11:21:05PM +0100, Mike Hommey wrote:\n> \n> > I use git-rebase quite regularly, and I haven't used git-rebase --skip\n> > after a failed merge without first resetting the working tree. I was\n> > wondering if it wouldn't make sense to automatically do the reset when\n> > running git-rebase --skip.\n> \n> I have often been annoyed by this behavior, too, and I can't think of\n> any situation where you _wouldn't_ want the reset to happen. But I\n> would be more comfortable hearing confirmation from others that they\n> can't think of such a situation.\n\nLet's take this history:\n\n C---D---E topic\n /\n A---B master\n\nYou then do:\ngit rebase master topic\n\nNow D causes conflicts, because B did a similar change, but not quite\nthe same, maybe having a bug. So you want to keep parts of D, but it's\nno longer the same commit semantically and the original commit message\nwould be bogus. So you resolve the conflicts and do:\n\ngit commit\ngit rebase --skip\n\nBecause you replaced D with a new different commit, instead of really\njust rebasing it. With plain --continue, you'd have to go back and fix\nthe commit message once the rebase is complete. And --continue after the\ncommit is a no-go, too, because rebase will complain that there's\nnothing left to produce the rebased D commit.\n\nAnd now imagine that you forget to commit but instead just --skip.\nOuch, all the work is lost, time to restart the rebase. With the current\nbehaviour, rebase won't just throw away your stuff.\n\nBjörn\n"},{"id":"58856","messageId":"4732E5A8.3020101@op5.se","threadId":"10710","inReplyTo":"20071108102412.GA31187@atjola.homenet","subject":"Re: git rebase --skip","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-11-08T10:32:08Z","receivedAt":"2007-11-08T10:32:08Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Björn Steinbrink wrote:\n> On 2007.11.07 22:23:10 -0500, Jeff King wrote:\n>> On Wed, Nov 07, 2007 at 11:21:05PM +0100, Mike Hommey wrote:\n>>\n>>> I use git-rebase quite regularly, and I haven't used git-rebase --skip\n>>> after a failed merge without first resetting the working tree. I was\n>>> wondering if it wouldn't make sense to automatically do the reset when\n>>> running git-rebase --skip.\n>> I have often been annoyed by this behavior, too, and I can't think of\n>> any situation where you _wouldn't_ want the reset to happen. But I\n>> would be more comfortable hearing confirmation from others that they\n>> can't think of such a situation.\n> \n> Let's take this history:\n> \n> C---D---E topic\n> /\n> A---B master\n> \n> You then do:\n> git rebase master topic\n> \n> Now D causes conflicts, because B did a similar change, but not quite\n> the same, maybe having a bug. So you want to keep parts of D, but it's\n> no longer the same commit semantically and the original commit message\n> would be bogus. So you resolve the conflicts and do:\n> \n> git commit\n> git rebase --skip\n> \n> Because you replaced D with a new different commit, instead of really\n> just rebasing it. With plain --continue, you'd have to go back and fix\n> the commit message once the rebase is complete. And --continue after the\n> commit is a no-go, too, because rebase will complain that there's\n> nothing left to produce the rebased D commit.\n> \n> And now imagine that you forget to commit but instead just --skip.\n> Ouch, all the work is lost, time to restart the rebase. With the current\n> behaviour, rebase won't just throw away your stuff.\n> \n\nHow about if the state to skip was stashed, the patch reapplied and the\ndifferences compared. If they were identical, go ahead and force the\nreset --hard, otherwise abort. That way, --skip will dwim only when\nit's safe, and all the lost work can be automagically created by\njust re-applying the patch again?\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"58858","messageId":"20071108104403.GB31187@atjola.homenet","threadId":"10710","inReplyTo":"4732E5A8.3020101@op5.se","subject":"Re: git rebase --skip","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2007-11-08T10:44:03Z","receivedAt":"2007-11-08T10:44:03Z","isPatch":false,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2007.11.08 11:32:08 +0100, Andreas Ericsson wrote:\n> Björn Steinbrink wrote:\n>> On 2007.11.07 22:23:10 -0500, Jeff King wrote:\n>>> On Wed, Nov 07, 2007 at 11:21:05PM +0100, Mike Hommey wrote:\n>>>\n>>>> I use git-rebase quite regularly, and I haven't used git-rebase --skip\n>>>> after a failed merge without first resetting the working tree. I was\n>>>> wondering if it wouldn't make sense to automatically do the reset when\n>>>> running git-rebase --skip.\n>>> I have often been annoyed by this behavior, too, and I can't think of\n>>> any situation where you _wouldn't_ want the reset to happen. But I\n>>> would be more comfortable hearing confirmation from others that they\n>>> can't think of such a situation.\n>>\n>> Let's take this history:\n>>\n>> C---D---E topic\n>> /\n>> A---B master\n>>\n>> You then do:\n>> git rebase master topic\n>>\n>> Now D causes conflicts, because B did a similar change, but not quite\n>> the same, maybe having a bug. So you want to keep parts of D, but it's\n>> no longer the same commit semantically and the original commit message\n>> would be bogus. So you resolve the conflicts and do:\n>>\n>> git commit\n>> git rebase --skip\n>>\n>> Because you replaced D with a new different commit, instead of really\n>> just rebasing it. With plain --continue, you'd have to go back and fix\n>> the commit message once the rebase is complete. And --continue after the\n>> commit is a no-go, too, because rebase will complain that there's\n>> nothing left to produce the rebased D commit.\n>>\n>> And now imagine that you forget to commit but instead just --skip.\n>> Ouch, all the work is lost, time to restart the rebase. With the current\n>> behaviour, rebase won't just throw away your stuff.\n>>\n>\n> How about if the state to skip was stashed, the patch reapplied and the\n> differences compared. If they were identical, go ahead and force the\n> reset --hard, otherwise abort. That way, --skip will dwim only when\n> it's safe, and all the lost work can be automagically created by\n> just re-applying the patch again?\n\nI'd prefer the --force option suggested in some other mail. Maybe I'm\njust not manly enough, but messing up a rebase can mean lots of\nduplicated work, so I'm rather happy with no dwim at all. Maybe for the\nreal manly users out there, add a rebase.alwaysForce option so they can\nlaugh at me for not using that ;-)\n\nBjörn\n"},{"id":"58926","messageId":"Pine.LNX.4.64.0711081332550.29952@iabervon.org","threadId":"10710","inReplyTo":"20071108102412.GA31187@atjola.homenet","subject":"Re: git rebase --skip","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2007-11-08T18:43:05Z","receivedAt":"2007-11-08T18:43:05Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Thu, 8 Nov 2007, Björn Steinbrink wrote:\n\n> On 2007.11.07 22:23:10 -0500, Jeff King wrote:\n> > On Wed, Nov 07, 2007 at 11:21:05PM +0100, Mike Hommey wrote:\n> > \n> > > I use git-rebase quite regularly, and I haven't used git-rebase --skip\n> > > after a failed merge without first resetting the working tree. I was\n> > > wondering if it wouldn't make sense to automatically do the reset when\n> > > running git-rebase --skip.\n> > \n> > I have often been annoyed by this behavior, too, and I can't think of\n> > any situation where you _wouldn't_ want the reset to happen. But I\n> > would be more comfortable hearing confirmation from others that they\n> > can't think of such a situation.\n> \n> Let's take this history:\n> \n> C---D---E topic\n> /\n> A---B master\n> \n> You then do:\n> git rebase master topic\n> \n> Now D causes conflicts, because B did a similar change, but not quite\n> the same, maybe having a bug. So you want to keep parts of D, but it's\n> no longer the same commit semantically and the original commit message\n> would be bogus. So you resolve the conflicts and do:\n> \n> git commit\n> git rebase --skip\n\nI guess that works, and nothing else presently does. But I don't think \nthat's at all intuitive as the correct thing to do (plus it feels too easy \nto get into losing your commit message). Maybe we should have a \"git \nrebase --amend\", which does the obvious thing (acts like --continue, but \nlets you edit the message). It's not like you just did something totally \ndifferent; the commit is still the replacement for D, it's just less the \nsame.\n\n\t-Daniel\n*This .sig left intentionally blank*"},{"id":"58929","messageId":"20071108191601.GA22353@glandium.org","threadId":"10710","inReplyTo":"Pine.LNX.4.64.0711081332550.29952@iabervon.org","subject":"Re: git rebase --skip","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2007-11-08T19:16:01Z","receivedAt":"2007-11-08T19:16:01Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Thu, Nov 08, 2007 at 01:43:05PM -0500, Daniel Barkalow wrote:\n> > git commit\n> > git rebase --skip\n> \n> I guess that works, and nothing else presently does. But I don't think \n> that's at all intuitive as the correct thing to do (plus it feels too easy \n> to get into losing your commit message). Maybe we should have a \"git \n> rebase --amend\", which does the obvious thing (acts like --continue, but \n> lets you edit the message). It's not like you just did something totally \n> different; the commit is still the replacement for D, it's just less the \n> same.\n\nMaybe some commands such as commit should fail or at least emit warning\nwhen used during a rebase ?\n\nMike\n"},{"id":"58930","messageId":"20071108192231.GA22658@glandium.org","threadId":"10710","inReplyTo":"20071108191601.GA22353@glandium.org","subject":"Re: git rebase --skip","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2007-11-08T19:22:31Z","receivedAt":"2007-11-08T19:22:31Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Thu, Nov 08, 2007 at 08:16:01PM +0100, Mike Hommey wrote:\n> On Thu, Nov 08, 2007 at 01:43:05PM -0500, Daniel Barkalow wrote:\n> > > git commit\n> > > git rebase --skip\n> > \n> > I guess that works, and nothing else presently does. But I don't think \n> > that's at all intuitive as the correct thing to do (plus it feels too easy \n> > to get into losing your commit message). Maybe we should have a \"git \n> > rebase --amend\", which does the obvious thing (acts like --continue, but \n> > lets you edit the message). It's not like you just did something totally \n> > different; the commit is still the replacement for D, it's just less the \n> > same.\n> \n> Maybe some commands such as commit should fail or at least emit warning\n> when used during a rebase ?\n\nOr, in the present case, doing the same as what \"edit\" would do in a\ngit-rebase --interactive could be enough.\n\nMike\n"},{"id":"58976","messageId":"Pine.LNX.4.64.0711082301020.4362@racer.site","threadId":"10710","inReplyTo":"20071108191601.GA22353@glandium.org","subject":"Re: git rebase --skip","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-08T23:01:43Z","receivedAt":"2007-11-08T23:01:43Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 8 Nov 2007, Mike Hommey wrote:\n\n> Maybe some commands such as commit should fail or at least emit warning \n> when used during a rebase ?\n\nNo, that would disrupt comming (and valid!) workflow too much. Even a \nwarning.\n\nCiao,\nDscho\n"},{"id":"58950","messageId":"20071108231632.GC29840@sigill.intra.peff.net","threadId":"10710","inReplyTo":"20071108104403.GB31187@atjola.homenet","subject":"Re: git rebase --skip","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-11-08T23:16:32Z","receivedAt":"2007-11-08T23:16:32Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Nov 08, 2007 at 11:44:03AM +0100, Björn Steinbrink wrote:\n\n> > How about if the state to skip was stashed, the patch reapplied and the\n> > differences compared. If they were identical, go ahead and force the\n> > reset --hard, otherwise abort. That way, --skip will dwim only when\n> > it's safe, and all the lost work can be automagically created by\n> > just re-applying the patch again?\n> \n> I'd prefer the --force option suggested in some other mail. Maybe I'm\n> just not manly enough, but messing up a rebase can mean lots of\n> duplicated work, so I'm rather happy with no dwim at all. Maybe for the\n> real manly users out there, add a rebase.alwaysForce option so they can\n> laugh at me for not using that ;-)\n\nPersonally, I don't see the point of a --force option; it turns your work\nflow from:\n\n 1. git-rebase --skip\n 2. Oops, I guess I have to reset.\n 3. git-reset --hard; git-rebase --skip\n\nto:\n\n 1. same as above\n 2. same as above\n 3. git-rebase --force --skip\n\nI guess it's a little bit easier to explain to new users, but it in no\nway eliminates the annoyance of \"I expected this to work, and it\ndidn't, so now I have to think about what happened and enter another\ncommand.\"\n\nAIUI, Andreas's proposal is not so much DWIM as \"do the obvious thing,\nbut include a safety valve to prevent throwing away work.\" Is there\nactually a case where it would not have the desired effect?\n\n-Peff\n"},{"id":"58984","messageId":"7vir4cz45z.fsf@gitster.siamese.dyndns.org","threadId":"10710","inReplyTo":"20071108231632.GC29840@sigill.intra.peff.net","subject":"Re: git rebase --skip","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-08T23:52:08Z","receivedAt":"2007-11-08T23:52:08Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> Personally, I don't see the point of a --force option; it turns your work\n> flow from:\n>\n> 1. git-rebase --skip\n> 2. Oops, I guess I have to reset.\n> 3. git-reset --hard; git-rebase --skip\n>\n> to:\n>\n> 1. same as above\n> 2. same as above\n> 3. git-rebase --force --skip\n\nI do not see it as improvement, either, for the same reason you\nstate.\n\n> AIUI, Andreas's proposal is not so much DWIM as \"do the obvious thing,\n> but include a safety valve to prevent throwing away work.\" Is there\n> actually a case where it would not have the desired effect?\n\nThe user is explicitly saying --skip, so I do not think it is\ndangerous even if we unconditionally did \"reset --hard\" at that\npoint.\n\nOr we could introduce a new option \"--drop\" (that's \"drop the\ncurrent commit and continue\") to do so, if people find that the\nword \"skip\" does not sound like a scary destructive operation.\n\nBut I do not think that is needed.\n"},{"id":"58962","messageId":"20071109010908.GA10781@atjola.homenet","threadId":"10710","inReplyTo":"7vir4cz45z.fsf@gitster.siamese.dyndns.org","subject":"Re: git rebase --skip","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2007-11-09T01:09:08Z","receivedAt":"2007-11-09T01:09:08Z","isPatch":false,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2007.11.08 15:52:08 -0800, Junio C Hamano wrote:\n> Jeff King writes:\n> \n> > Personally, I don't see the point of a --force option; it turns your work\n> > flow from:\n> >\n> > 1. git-rebase --skip\n> > 2. Oops, I guess I have to reset.\n> > 3. git-reset --hard; git-rebase --skip\n> >\n> > to:\n> >\n> > 1. same as above\n> > 2. same as above\n> > 3. git-rebase --force --skip\n> \n> I do not see it as improvement, either, for the same reason you\n> state.\n> \n> > AIUI, Andreas's proposal is not so much DWIM as \"do the obvious thing,\n> > but include a safety valve to prevent throwing away work.\" Is there\n> > actually a case where it would not have the desired effect?\n> \n> The user is explicitly saying --skip, so I do not think it is\n> dangerous even if we unconditionally did \"reset --hard\" at that\n> point.\n\nThe user _must_ say --skip in the case I outlined. And I'm pretty sure\nthat the first thing I'll (accidently) do once --skip implies \"reset\n--hard\" is to forget to commit. Murphy has never let me down.\n\nHow about adding that --amend option that someone mentioned? Or even\njust letting --continue act like --skip when there's nothing to commit.\nThat way, you're no longer forced to use --skip.\n\nBjörn\n"},{"id":"58987","messageId":"20071109032227.GA31760@sigill.intra.peff.net","threadId":"10710","inReplyTo":"7vir4cz45z.fsf@gitster.siamese.dyndns.org","subject":"Re: git rebase --skip","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-11-09T03:22:29Z","receivedAt":"2007-11-09T03:22:29Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Nov 08, 2007 at 03:52:08PM -0800, Junio C Hamano wrote:\n\n> The user is explicitly saying --skip, so I do not think it is\n> dangerous even if we unconditionally did \"reset --hard\" at that\n> point.\n\nSure, I think the complaint is not that \"reset --hard\" is the wrong\nbehavior, but that people are prone to type --skip in error. Right now\nwe handle that error in a data-preserving way (we complain, and the user\nhas to think and issue a \"throw away this data\" command), but automatic\nreset is less safe (even though there are fewer times when somebody\nmeant to commit instead of just reset, the consequences are harder to\nrecover from).\n\nI've never personally run into this, but I think it is a reasonable\nthing to think about, and if it is easy to add an additional safety\nvalve (either stashing the index/wt state, or checking before automatic\n\"reset --hard\" whether any work has been done towards resolving), then\nwe probably should.\n\nSo I am fine with the original patch (unconditional reset --hard), but\nit would be nice to see the people who care submit concrete proposals\nfor such a safety valve.\n\n> Or we could introduce a new option \"--drop\" (that's \"drop the\n> current commit and continue\") to do so, if people find that the\n> word \"skip\" does not sound like a scary destructive operation.\n\nI don't think the problem is \"users don't realize how scary --skip can\nbe\", but rather \"I use --skip to resolve this situation 99% of the time,\nso in the other 1%, I soetimes use it accidentally.\"\n\n-Peff\n"},{"id":"59017","messageId":"Pine.LNX.4.64.0711091056530.4362@racer.site","threadId":"10710","inReplyTo":"20071109032227.GA31760@sigill.intra.peff.net","subject":"Re: git rebase --skip","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-09T10:59:57Z","receivedAt":"2007-11-09T10:59:57Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 8 Nov 2007, Jeff King wrote:\n\n> So I am fine with the original patch (unconditional reset --hard), but \n> it would be nice to see the people who care submit concrete proposals \n> for such a safety valve.\n\nIsn't having to say \"--skip\" instead of \"--continue\" enough? Some people \nmight complain that it's too easy to get your fingers wired to type \n--skip.\n\nIn that case, I might beg to differ for two reasons: --skip is definitely \nnot the default operation, so the fingers do not get any chance to do \nthat, and even if, they would get wired to --force --skip just as easily.\n\nBesides, after my patch to rebase on a detached HEAD, it is very easy to \ngo back to the original state and try again.\n\nCiao,\nDscho\n"},{"id":"59075","messageId":"20071109161945.GA26826@fieldses.org","threadId":"10710","inReplyTo":"Pine.LNX.4.64.0711091056530.4362@racer.site","subject":"Re: git rebase --skip","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2007-11-09T16:19:46Z","receivedAt":"2007-11-09T16:19:46Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Fri, Nov 09, 2007 at 10:59:57AM +0000, Johannes Schindelin wrote:\n> Hi,\n> \n> On Thu, 8 Nov 2007, Jeff King wrote:\n> \n> > So I am fine with the original patch (unconditional reset --hard), but \n> > it would be nice to see the people who care submit concrete proposals \n> > for such a safety valve.\n> \n> Isn't having to say \"--skip\" instead of \"--continue\" enough? Some people \n> might complain that it's too easy to get your fingers wired to type \n> --skip.\n> \n> In that case, I might beg to differ for two reasons: --skip is definitely \n> not the default operation, so the fingers do not get any chance to do \n> that, and even if, they would get wired to --force --skip just as easily.\n> \n> Besides, after my patch to rebase on a detached HEAD, it is very easy to \n> go back to the original state and try again.\n\nWe can't make --skip do an automatic reset --hard. I expect --skip to\ntell me if I haven't finished resolving conflicts. If it doesn't do\nthat, I'll lose work. I can't be the only user with that expectation.\n\n(To be more specific: the work I lose is the work spent resolving how\nhowever many conflicts I've dealt with so far. It isn't always the case\nthat I get to a certain point in a rebase and say \"ah, yes, I know this\nis already applied, I can reset and skip it.\" More often I want to go\nthrough each conflict and decide individually. So I do that for a few,\nI run --continue or --skip when I think I'm done (but don't actually\ncheck first, 'cause I count on rebase to do that), then fix up anything\nremaining.)\n\n--b.\n"},{"id":"59076","messageId":"20071109162634.GB26826@fieldses.org","threadId":"10710","inReplyTo":"20071109161945.GA26826@fieldses.org","subject":"Re: git rebase --skip","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2007-11-09T16:26:34Z","receivedAt":"2007-11-09T16:26:34Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Fri, Nov 09, 2007 at 11:19:46AM -0500, J. Bruce Fields wrote:\n> On Fri, Nov 09, 2007 at 10:59:57AM +0000, Johannes Schindelin wrote:\n> > Hi,\n> > \n> > On Thu, 8 Nov 2007, Jeff King wrote:\n> > \n> > > So I am fine with the original patch (unconditional reset --hard), but \n> > > it would be nice to see the people who care submit concrete proposals \n> > > for such a safety valve.\n> > \n> > Isn't having to say \"--skip\" instead of \"--continue\" enough? Some people \n> > might complain that it's too easy to get your fingers wired to type \n> > --skip.\n> > \n> > In that case, I might beg to differ for two reasons: --skip is definitely \n> > not the default operation, so the fingers do not get any chance to do \n> > that, and even if, they would get wired to --force --skip just as easily.\n> > \n> > Besides, after my patch to rebase on a detached HEAD, it is very easy to \n> > go back to the original state and try again.\n> \n> We can't make --skip do an automatic reset --hard. I expect --skip to\n> tell me if I haven't finished resolving conflicts. If it doesn't do\n> that, I'll lose work. I can't be the only user with that expectation.\n> \n> (To be more specific: the work I lose is the work spent resolving how\n> however many conflicts I've dealt with so far. It isn't always the case\n> that I get to a certain point in a rebase and say \"ah, yes, I know this\n> is already applied, I can reset and skip it.\" More often I want to go\n> through each conflict and decide individually. So I do that for a few,\n> I run --continue or --skip when I think I'm done (but don't actually\n> check first, 'cause I count on rebase to do that), then fix up anything\n> remaining.)\n\n(Eh, now that I think of it: what I actually usually do is run\n--continue, git says there's one more conflict, I fix that up and run\n--continue again, it tells me there's nothing to commit, I say huh?\nThen eventually I remember I need to run --skip instead, cursing it for\nnot just figuring that out on its own.... So actually it may be that\nthe only time I run --skip is after --continue has told me I need to. I\ncan't *swear* that that's the case, so I'm still nervous about the idea\nof --skip automatically resetting. Oh well. Take that one user's\nexperience for what it's worth.)\n\n--b.\n"},{"id":"59087","messageId":"20071109172014.GA12523@sigill.intra.peff.net","threadId":"10710","inReplyTo":"Pine.LNX.4.64.0711091056530.4362@racer.site","subject":"Re: git rebase --skip","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-11-09T17:20:15Z","receivedAt":"2007-11-09T17:20:15Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Nov 09, 2007 at 10:59:57AM +0000, Johannes Schindelin wrote:\n\n> Isn't having to say \"--skip\" instead of \"--continue\" enough? Some people \n> might complain that it's too easy to get your fingers wired to type \n> --skip.\n\nThey already have.\n\n> Besides, after my patch to rebase on a detached HEAD, it is very easy to \n> go back to the original state and try again.\n\nBut you are losing any work you did in resolving merges.\n\n\nBut I don't personally have this problem, so I will stop defending those\nwho claim to, and let them speak for themselves (hopefully with\npatches!).\n\n-Peff\n"}]}