{"thread":{"id":"28665","subject":"git rebase +","startedAt":"2011-10-13T11:48:39Z","lastAt":"2011-10-17T10:03:23Z","messageCount":7,"participants":["Adam Piatyszek","Johannes Sixt","Jonathan Nieder","Martin von Zweigbergk","Ramkumar Ramachandra"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"177541","messageId":"loom.20111013T134405-495@post.gmane.org","threadId":"28665","inReplyTo":null,"subject":"git rebase +","fromName":"Adam Piatyszek","fromEmail":"ediap@wp.pl","sentAt":"2011-10-13T11:48:39Z","receivedAt":"2011-10-13T11:48:39Z","isPatch":false,"sender":{"key":"ediap@wp.pl","avatar":null},"body":"Hi,\n\nIn the middle of \"git rebase --continue\" process I hit Ctrl+C today to break\nthis operation. When I tried to replay the same command it errors out with the \nfollowing problem:\n\nediap@stsrdt1:src/toolfiles: git rebase --continue\nRebasing (2/3)\n\n[Ctrl+C was hit here]\n\nediap@stsrdt1:src/toolfiles: git rebase --continue\n/project/dfttools/libexec/git-core/git-rebase--interactive: line 650: \n/home/ediap/project.git/.git/rebase-merge/author-script: No such file or \ndirectory\n\nIs this an expected behavior?\n\nThanks,\n/Adam\n"},{"id":"177551","messageId":"4E96E5E1.7010103@viscovery.net","threadId":"28665","inReplyTo":"loom.20111013T134405-495@post.gmane.org","subject":"Re: git rebase +","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2011-10-13T13:21:37Z","receivedAt":"2011-10-13T13:21:37Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 10/13/2011 13:48, schrieb Adam Piatyszek:\n> In the middle of \"git rebase --continue\" process I hit Ctrl+C today to break\n> this operation. When I tried to replay the same command it errors out with the \n> following problem:\n> /project/dfttools/libexec/git-core/git-rebase--interactive: line 650: \n> /home/ediap/project.git/.git/rebase-merge/author-script: No such file or \n> directory\n> \n> Is this an expected behavior?\n\nHitting Ctrl-C during git-rebase results undefined behavior. git-rebase is\na shell script and was never designed to operate in any form of atomicity.\n\nYou should have let it run until it stopped. Then you could have said 'git\nrebase --abort' (if it didn't complete) or 'git reset --hard ORIG_HEAD'\n(if it completed).\n\n-- Hannes\n"},{"id":"177608","messageId":"20111014052653.GA5052@elie.hsd1.il.comcast.net","threadId":"28665","inReplyTo":"4E96E5E1.7010103@viscovery.net","subject":"interrupting \"git rebase\" (Re: git rebase +)","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-10-14T05:26:53Z","receivedAt":"2011-10-14T05:26:53Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Johannes Sixt wrote:\n\n> Hitting Ctrl-C during git-rebase results undefined behavior. git-rebase is\n> a shell script and was never designed to operate in any form of atomicity.\n>\n> You should have let it run until it stopped.\n\nWait, really? That's bad, and unlike most git commands.\n\n> Then you could have said 'git\n> rebase --abort' (if it didn't complete) or 'git reset --hard ORIG_HEAD'\n> (if it completed).\n\nIf interrupting the rebase leaves the repository in a state that\n\n\trm -fr .git/rebase-apply\n\tgit reset --hard \n\ncannot recover from, I'd consider it a serious problem.\n\nBy the way, what happened to the \"git rebase --abort-softly\" synonym\nfor \"rm -fr .git/rebase-apply\" discussed a while ago?\n"},{"id":"177609","messageId":"20111014052904.GB401@elie.hsd1.il.comcast.net","threadId":"28665","inReplyTo":"20111014052653.GA5052@elie.hsd1.il.comcast.net","subject":"Re: interrupting \"git rebase\" (Re: git rebase +)","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-10-14T05:29:04Z","receivedAt":"2011-10-14T05:29:04Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Jonathan Nieder wrote:\n\n> By the way, what happened to the \"git rebase --abort-softly\" synonym\n> for \"rm -fr .git/rebase-apply\" discussed a while ago?\n\n(Here's a pointer I should have included[1]. Sorry for the noise.)\n\n[1] http://thread.gmane.org/gmane.comp.version-control.git/174655\n"},{"id":"177732","messageId":"CAOeW2eFK5vSKmf+nxzD-6yh5CWZRv4WqSerbSXTPtXmtNeNjxg@mail.gmail.com","threadId":"28665","inReplyTo":"20111014052653.GA5052@elie.hsd1.il.comcast.net","subject":"Re: interrupting \"git rebase\" (Re: git rebase +)","fromName":"Martin von Zweigbergk","fromEmail":"martin.von.zweigbergk@gmail.com","sentAt":"2011-10-15T15:23:23Z","receivedAt":"2011-10-15T15:23:23Z","isPatch":false,"sender":{"key":"martinvonz@gmail.com","avatar":"https://avatars.githubusercontent.com/u/891642?v=4"},"body":"On Thu, Oct 13, 2011 at 10:26 PM, Jonathan Nieder wrote:\n> Johannes Sixt wrote:\n>\n>> Hitting Ctrl-C during git-rebase results undefined behavior. git-rebase is\n>> a shell script and was never designed to operate in any form of atomicity.\n>>\n>> You should have let it run until it stopped.\n>\n> Wait, really?  That's bad, and unlike most git commands.\n\nIf Ctrl-C is pressed while the state is being written, it could be\nleft with incomplete information, yes. It has been like that forever I\nthink. I'll put it on my todo list, but it will not be my top priority\n(and I have very little git time now anyways).\n\n> If interrupting the rebase leaves the repository in a state that\n>\n>        rm -fr .git/rebase-apply\n>        git reset --hard \n>\n> cannot recover from, I'd consider it a serious problem.\n\nI agree, but I don't know of any way that can happen. Even \"git rebase\n--abort\" should always work (in the sense that\n.git/rebase-[apply|merge] would be deleted), although it will not\nreturn to the original branch if some state is missing.\n\n> By the way, what happened to the \"git rebase --abort-softly\" synonym\n> for \"rm -fr .git/rebase-apply\" discussed a while ago?\n\nI think we simply did not agree on a syntax, but here was also some\ndiscussion about future plans for the sequencer. I remember seeing\nsome discussions about making \"git reset --hard\" remove the sequencer\nstate, but I don't remember the conclusion. It is not clear to me what\nis ok to implement in git-rebase nowadays and what would just be\ndouble work if it needs to be re-implemented in the sequencer.\n\nMartin\n"},{"id":"177742","messageId":"20111015194414.GB12893@elie.hsd1.il.comcast.net","threadId":"28665","inReplyTo":"CAOeW2eFK5vSKmf+nxzD-6yh5CWZRv4WqSerbSXTPtXmtNeNjxg@mail.gmail.com","subject":"Re: interrupting \"git rebase\" (Re: git rebase +)","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-10-15T19:44:14Z","receivedAt":"2011-10-15T19:44:14Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"(+cc: Ram)\nMartin von Zweigbergk wrote:\n> On Thu, Oct 13, 2011 at 10:26 PM, Jonathan Nieder wrote:\n>> Johannes Sixt wrote:\n\n>>> Hitting Ctrl-C during git-rebase results undefined behavior.\n[...]\n>> Wait, really?  That's bad, and unlike most git commands.\n>\n> If Ctrl-C is pressed while the state is being written, it could be\n> left with incomplete information, yes. It has been like that forever I\n> think. I'll put it on my todo list, but it will not be my top priority\n> (and I have very little git time now anyways).\n\nSorry for the lack of clarity. That actually sounds fine to me\nalready, as long as the intermediate state is easy to recover from\n(which doesn't match what I usually think of as \"undefined behavior\").\n\nSo it sounds like I was worrying needlessly.\n\n[...]\n>> By the way, what happened to the \"git rebase --abort-softly\" synonym\n>> for \"rm -fr .git/rebase-apply\" discussed a while ago?\n>\n> I think we simply did not agree on a syntax, but here was also some\n> discussion about future plans for the sequencer. I remember seeing\n> some discussions about making \"git reset --hard\" remove the sequencer\n> state, but I don't remember the conclusion. It is not clear to me what\n> is ok to implement in git-rebase nowadays and what would just be\n> double work if it needs to be re-implemented in the sequencer.\n\nI believe a good rule of thumb is that you can always pretend the\nsequencer just doesn't exist, and cc Ram when you are unsure. :)\n\nCertainly, a lot of sequencer features were inspired by \"git rebase\".\nImprovements to \"git rebase\" are only likely to make future\nimprovements to \"git sequencer\" easier. Part of what helps here is\nthat \"git rebase\" is a shell script, so it is a little easier to\nprototype features there.\n\nThanks!\nJonathan\n"},{"id":"177854","messageId":"CALkWK0=QfXcFD7-0-Pz_uGPp5fNpRHqqgcYPXRR7=7uq92mzGg@mail.gmail.com","threadId":"28665","inReplyTo":"20111015194414.GB12893@elie.hsd1.il.comcast.net","subject":"Re: interrupting \"git rebase\" (Re: git rebase +)","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2011-10-17T10:03:23Z","receivedAt":"2011-10-17T10:03:23Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Hi,\n\nJonathan Nieder writes:\n> Martin von Zweigbergk wrote:\n>> On Thu, Oct 13, 2011 at 10:26 PM, Jonathan Nieder wrote:\n>>> Johannes Sixt wrote:\n>\n>>>> Hitting Ctrl-C during git-rebase results undefined behavior.\n> [...]\n>>> Wait, really?  That's bad, and unlike most git commands.\n>>\n>> If Ctrl-C is pressed while the state is being written, it could be\n>> left with incomplete information, yes. It has been like that forever I\n>> think. I'll put it on my todo list, but it will not be my top priority\n>> (and I have very little git time now anyways).\n> [...]\n\nAh, yes. I've been bitten by this behavior several times myself :)\n\n>>> By the way, what happened to the \"git rebase --abort-softly\" synonym\n>>> for \"rm -fr .git/rebase-apply\" discussed a while ago?\n>>\n>> I think we simply did not agree on a syntax, but here was also some\n>> discussion about future plans for the sequencer. I remember seeing\n>> some discussions about making \"git reset --hard\" remove the sequencer\n>> state, but I don't remember the conclusion. It is not clear to me what\n>> is ok to implement in git-rebase nowadays and what would just be\n>> double work if it needs to be re-implemented in the sequencer.\n> [...]\n> Certainly, a lot of sequencer features were inspired by \"git rebase\".\n> Improvements to \"git rebase\" are only likely to make future\n> improvements to \"git sequencer\" easier.  Part of what helps here is\n> that \"git rebase\" is a shell script, so it is a little easier to\n> prototype features there.\n\nI concur. Work on `git rebase` should continue independently of the\nsequencer because that's where we pick up ideas from! I don't see it\nas double-work: simply a translation of ideas. Apart from the fixup\nmini-series, the overall interface of the sequencer is still very\nunclear to me (see long discussion with Junio, Jonathan).\n\nYes, 95eb88 (reset: Make reset remove the sequencer state, 2011-08-04)\nis merged. But it's pretty unrelated to the main issue at hand: sure,\n\"reset --hard\" is a great hammer, but that shouldn't prevent us from\ndeveloping tools and interfaces that are more sophisticated and\nelegant, no? In other words, I think \"--abort-softly\" is a great\nidea: we should pour ideas into our shell scripts!\n\nThanks.\n\n-- Ram\n"}]}