{"thread":{"id":"27488","subject":"[PATCH] rebase: learn --discard subcommand","startedAt":"2011-05-28T02:58:15Z","lastAt":"2011-05-30T08:44:05Z","messageCount":17,"participants":["Martin von Zweigbergk","Ramkumar Ramachandra","Junio C Hamano","Tim Mazid","Jonathan Nieder","Jakub Narebski","Michael Haggerty","Miles Bader"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"168907","messageId":"1306551495-26685-1-git-send-email-martin.von.zweigbergk@gmail.com","threadId":"27488","inReplyTo":null,"subject":"[PATCH] rebase: learn --discard subcommand","fromName":"Martin von Zweigbergk","fromEmail":"martin.von.zweigbergk@gmail.com","sentAt":"2011-05-28T02:58:15Z","receivedAt":"2011-05-28T02:58:15Z","isPatch":true,"sender":{"key":"martinvonz@gmail.com","avatar":"https://avatars.githubusercontent.com/u/891642?v=4"},"body":"Teach git-rebase the --discard subcommand, which is similar to\n--abort, but does not move back to the original branch. Suggest this\nnew subcommand to the user where we currently suggest to delete\n$GIT_DIR/rebase-apply (or rebase-merge).\n\nSigned-off-by: Martin von Zweigbergk \n---\n\nA long time ago I said I wished that 'git rebase --abort' would move\nback to the where HEAD was when the rebase was initiated, instead of\nmoving back to the branch that was about to be rebased (which may be\ndifferent for \"git rebase $upstream $branch\"). I think Junio then\nhinted that he sometimes wished that he could abort rebase without\nmoving to anywhere else at all, which is what this patch implements. I\ndon't feel strongly about this patch, but I would probably also use\nthis subcommand once in a while. However, maybe the greatest value in\nit is that we don't have to tell users to mess with the .git\ndirectory?\n\nI used \"rm -r\" without -f to match how it is done in --abort, but\nmaybe -f should be used? That is what we recommend to the end-user to\nuse today.\n\nA difference from --abort is that --discard does not clear\nrerere. Need this be mentioned in the documentation?\n\nI have not been involved in Ramkumar's work on the sequencer to know\nif and how this might impact it.\n\n\n Documentation/git-rebase.txt | 5 ++++-\n git-rebase.sh | 17 +++++++++++------\n 2 files changed, 15 insertions(+), 7 deletions(-)\n\ndiff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt\nindex 9a075bc..e841c21 100644\n--- a/Documentation/git-rebase.txt\n+++ b/Documentation/git-rebase.txt\n@@ -13,7 +13,7 @@ SYNOPSIS\n 'git rebase' [-i | --interactive] [options] --onto \n \t--root []\n \n-'git rebase' --continue | --skip | --abort\n+'git rebase' --continue | --skip | --abort | --discard\n \n DESCRIPTION\n -----------\n@@ -238,6 +238,9 @@ leave out at most one of A and B, in which case it defaults to HEAD.\n --skip::\n \tRestart the rebasing process by skipping the current patch.\n \n+--discard::\n+\tAbort the rebase operation without restoring the original branch.\n+\n -m::\n --merge::\n \tUse merging strategies to rebase. When the recursive (default) merge\ndiff --git a/git-rebase.sh b/git-rebase.sh\nindex 7a54bfc..befee92 100755\n--- a/git-rebase.sh\n+++ b/git-rebase.sh\n@@ -32,7 +32,7 @@ OPTIONS_KEEPDASHDASH=\n OPTIONS_SPEC=\"\\\n git rebase [-i] [options] [--onto ] [] []\n git rebase [-i] [options] --onto --root []\n-git-rebase [-i] --continue | --abort | --skip\n+git-rebase [-i] --continue | --abort | --skip | --discard\n --\n Available options are\n v,verbose! display a diffstat of what changed upstream\n@@ -60,6 +60,7 @@ C=! passed to 'git apply'\n continue! continue rebasing process\n abort! abort rebasing process and restore original branch\n skip! skip current patch and continue rebasing process\n+discard! abort rebasing process, but do not restore original branch\n \"\n . git-sh-setup\n set_reflog_action rebase\n@@ -93,7 +94,7 @@ in_progress=\n type=\n # One of {\"$GIT_DIR\"/rebase-apply, \"$GIT_DIR\"/rebase-merge}\n state_dir=\n-# One of {'', continue, skip, abort}, as parsed from command line\n+# One of {'', continue, skip, abort, discard}, as parsed from command line\n action=\n preserve_merges=\n autosquash=\n@@ -206,7 +207,7 @@ do\n \t--verify)\n \t\tok_to_skip_pre_rebase=\n \t\t;;\n-\t--continue|--skip|--abort)\n+\t--continue|--skip|--abort|--discard)\n \t\ttest $total_argc -eq 2 || usage\n \t\taction=${1##--}\n \t\t;;\n@@ -340,6 +341,10 @@ abort)\n \trm -r \"$state_dir\"\n \texit\n \t;;\n+discard)\n+\trm -r \"$state_dir\"\n+\texit\n+\t;;\n esac\n \n # Make sure no rebase is in progress\n@@ -349,9 +354,9 @@ then\n It seems that there is already a '\"${state_dir##*/}\"' directory, and\n I wonder if you are in the middle of another rebase. If that is the\n case, please try\n-\tgit rebase (--continue | --abort | --skip)\n-If that is not the case, please\n-\trm -fr '\"$state_dir\"'\n+\tgit rebase (--continue | --abort | --skip | --discard)\n+If that is not the case, please run\n+\tgit rebase --discard\n and run me again. I am stopping in case you still have something\n valuable there.'\n fi\n-- \n1.7.4.79.gcbe20\n"},{"id":"168912","messageId":"BANLkTim-Wva018BFeTUPqZuiK02-X01XJQ@mail.gmail.com","threadId":"27488","inReplyTo":"1306551495-26685-1-git-send-email-martin.von.zweigbergk@gmail.com","subject":"Re: [PATCH] rebase: learn --discard subcommand","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2011-05-28T13:15:16Z","receivedAt":"2011-05-28T13:15:16Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Hi Martin,\n\nMartin von Zweigbergk writes:\n> A long time ago I said I wished that 'git rebase --abort' would move\n> back to the where HEAD was when the rebase was initiated, instead of\n> moving back to the branch that was about to be rebased (which may be\n> different for \"git rebase $upstream $branch\"). I think Junio then\n> hinted that he sometimes wished that he could abort rebase without\n> moving to anywhere else at all, which is what this patch implements. I\n> don't feel strongly about this patch, but I would probably also use\n> this subcommand once in a while. However, maybe the greatest value in\n> it is that we don't have to tell users to mess with the .git\n> directory?\n\nInteresting. Yes, I usually remove the state file by hand too. In view\nof \"git rebase --interactive\" being a porcelain command, I don't know\nif it's alright to drop the user into a detached HEAD state.\n\n> I used \"rm -r\" without -f to match how it is done in --abort, but\n> maybe -f should be used? That is what we recommend to the end-user to\n> use today.\n\nIf you've verified that a rebase is already in progress, I don't see\nthe point of using '-f'. Otherwise, it should error out and say that\n\"no rebase is in progress\", like the other command-line options\ncurrently do.\n\n> A difference from --abort is that --discard does not clear\n> rerere. Need this be mentioned in the documentation?\n\nIt depends on what you're expecting the user to do in this detached\nHEAD state, no?\n\n> I have not been involved in Ramkumar's work on the sequencer to know\n> if and how this might impact it.\n\nIt'll have no impact on the Sequencer work. Thanks.\n\n-- Ram\n"},{"id":"168922","messageId":"7vpqn2psjv.fsf@alter.siamese.dyndns.org","threadId":"27488","inReplyTo":"1306551495-26685-1-git-send-email-martin.von.zweigbergk@gmail.com","subject":"Re: [PATCH] rebase: learn --discard subcommand","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-05-28T18:51:32Z","receivedAt":"2011-05-28T18:51:32Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Martin von Zweigbergk writes:\n\n> ... I think Junio then\n> hinted that he sometimes wished that he could abort rebase without\n> moving to anywhere else at all, which is what this patch implements.\n\nI am not opposed to this particular patch, but thinking about a bigger\npicture, I am not sure if we want to solve it this way.\n\nWe have multiple \"sequence\" operations that want to do things in multiple\nsteps, each of which can stop and give control back to the user, while\nleaving some information in the .git directory for it to know where it was\nwhen resuming. I think \"am\" knows about what \"rebase\" does (and\nvice-versa) so it can detect an attempt to run it while \"rebase\" is in\nstill progress and refuse to continue to limit the damage, but if we have\nN such \"sequence\" commands that want to refrain from interfering with each\nother, and want to offer an advice to abort the in-progress operation\ninitiated by other commands, that would mean we would need N * N pieces of\nlogic to detect other's in-limbo state and offer advices, which would not\nscale.\n\nA user who is given back the control from a \"sequence\" operation may be\nconfused either (1) immediately after such an event (often some sort of\nmerge conflict) or (2) much later after first abandoning the working tree\naltogether and taking a walk and then coming back to continue working\nwhile forgetting what he was doing. Such a user may want to say \"I know I\nam in a strange state, give me a state that I can work from, at this point\nI do not care about continuing what I was originally doing\". The user may\nprobably not know if \"git rebase\" was in progress or \"git cherry-pick\"\nwas.\n\n\"git reset --hard\" used to be such a command in simpler times. It removes\nMERGE_HEAD unconditionally, so that a confused user can start from scratch\nwithout having to worry about what was in progress. As a devil's advocate,\nI am wondering if it is a good idea to simply teach \"reset --hard\" to also\nremove any and all \"sequence\" cruft (.git/rebase-apply, .git/rebase-merge,\nCHERRY_PICK_HEAD; we might have others I do not recall offhand) and be\ndone with it. It is a large hammer, but it is certainly the easiest to\nexplain and the simplest to understand way to get out of any troubles.\n"},{"id":"168926","messageId":"SNT124-W247D44D043F692CA06747EC4790@phx.gbl","threadId":"27488","inReplyTo":"7vpqn2psjv.fsf@alter.siamese.dyndns.org","subject":"RE: [PATCH] rebase: learn --discard subcommand","fromName":"Tim Mazid","fromEmail":"timmazid@hotmail.com","sentAt":"2011-05-28T20:26:26Z","receivedAt":"2011-05-28T20:26:26Z","isPatch":true,"sender":{"key":"timmazid@hotmail.com","avatar":null},"body":"\n> From: gitster@pobox.com\n> Date: Sat, 28 May 2011 11:51:32 -0700\n>\n> Martin von Zweigbergk writes:\n>\n> > ... I think Junio then\n> > hinted that he sometimes wished that he could abort rebase without\n> > moving to anywhere else at all, which is what this patch implements.\n>\n> I am not opposed to this particular patch, but thinking about a bigger\n> picture, I am not sure if we want to solve it this way.\n>\n> We have multiple \"sequence\" operations that want to do things in multiple\n> steps, each of which can stop and give control back to the user, while\n> leaving some information in the .git directory for it to know where it was\n> when resuming. I think \"am\" knows about what \"rebase\" does (and\n> vice-versa) so it can detect an attempt to run it while \"rebase\" is in\n> still progress and refuse to continue to limit the damage, but if we have\n> N such \"sequence\" commands that want to refrain from interfering with each\n> other, and want to offer an advice to abort the in-progress operation\n> initiated by other commands, that would mean we would need N * N pieces of\n> logic to detect other's in-limbo state and offer advices, which would not\n> scale.\n>\n> A user who is given back the control from a \"sequence\" operation may be\n> confused either (1) immediately after such an event (often some sort of\n> merge conflict) or (2) much later after first abandoning the working tree\n> altogether and taking a walk and then coming back to continue working\n> while forgetting what he was doing. Such a user may want to say \"I know I\n> am in a strange state, give me a state that I can work from, at this point\n> I do not care about continuing what I was originally doing\". The user may\n> probably not know if \"git rebase\" was in progress or \"git cherry-pick\"\n> was.\n>\n> \"git reset --hard\" used to be such a command in simpler times. It removes\n> MERGE_HEAD unconditionally, so that a confused user can start from scratch\n> without having to worry about what was in progress. As a devil's advocate,\n> I am wondering if it is a good idea to simply teach \"reset --hard\" to also\n> remove any and all \"sequence\" cruft (.git/rebase-apply, .git/rebase-merge,\n> CHERRY_PICK_HEAD; we might have others I do not recall offhand) and be\n> done with it. It is a large hammer, but it is certainly the easiest to\n> explain and the simplest to understand way to get out of any troubles.\n\nI'd just like to say that I sometime use \"git reset --hard\" in the middle\nof a \"git rebase\" when I want to get rid of some changes completely.\nNow, I'm not saying that this is the best way of doing it (\"git checkout --\"\nis probably far superior?), but I daresay that there are some users out\nthere who will be surprised by the new behaviour of \"git reset --hard\".\n\nHaving said that, before I knew that \"git reset --hard\" could be used\nin the middle of a rebase without aborting the reset, I did try to use it\nto abort the rebase, because, as you said, it seems to be \"uh oh\" button\nin git.\n\nSo it's a bit of a toss-up really.\n\nHaving said that, I would support making \"reset --hard\" abort rebases,\non the condition that there are some _big_ warnings somewhere about\nthe change in behaviour.\n\n\nTim.\n\n() ascii ribbon campaign - against html e-mail\n/\\ www.asciiribbon.org    - against proprietary attachments\n \t\t \t \t\t "},{"id":"168933","messageId":"20110528225046.GA31449@elie","threadId":"27488","inReplyTo":"SNT124-W247D44D043F692CA06747EC4790@phx.gbl","subject":"Re: [PATCH] rebase: learn --discard subcommand","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-05-28T22:50:46Z","receivedAt":"2011-05-28T22:50:46Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nTim Mazid wrote:\n\n> I'd just like to say that I sometime use \"git reset --hard\" in the middle\n> of a \"git rebase\" when I want to get rid of some changes completely.\n> Now, I'm not saying that this is the best way of doing it (\"git checkout --\"\n> is probably far superior?)\n\n . \"git checkout -- .\" to discard unadded changes\n . \"git checkout HEAD -- .\" to discard uncommitted changes\n . \"git reset --keep HEAD^\" to work against a different commit\n . \"git reset --merge\" to discard a merge resolution in progress\n\nWhile I also would be happy to see \"git reset --hard\" to abort\nam/rebase, I see two problems, one with an obvious solution, the other\nnot:\n\n1. It would be a big change in behavior that directly goes against\nmuscle memory, as you mentioned. This part could be mitigated by\nproviding \"undo\" functionality (e.g., renaming the .git/rebase-merge\ndirectory instead of deleting it) and printing advice including a\ncommand that gets the sequencer state back.\n\n2. It does not help people like me who are fearful about scribbling\nover accidentally unstaged or uncommitted changes. This could be\nmitigated by also providing forget-sequence functionality through\nseparate commands like \"git rebase --discard\".\n"},{"id":"168934","messageId":"20110528230844.GA31498@elie","threadId":"27488","inReplyTo":"1306551495-26685-1-git-send-email-martin.von.zweigbergk@gmail.com","subject":"Re: [PATCH] rebase: learn --discard subcommand","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-05-28T23:08:44Z","receivedAt":"2011-05-28T23:08:44Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nMartin von Zweigbergk wrote:\n\n> Teach git-rebase the --discard subcommand, which is similar to\n> --abort, but does not move back to the original branch. Suggest this\n> new subcommand to the user where we currently suggest to delete\n> $GIT_DIR/rebase-apply (or rebase-merge).\n\nGood idea.\n\nAt first the name --discard made me think it was going to move back to\nthe original branch and discard the reset of the patch series being\nrebased. Not sure what a better name would be, though.\n\n> --- a/Documentation/git-rebase.txt\n> +++ b/Documentation/git-rebase.txt\n> @@ -238,6 +238,9 @@ leave out at most one of A and B, in which case it defaults to HEAD.\n[...]\n> +--discard::\n> +\tAbort the rebase operation without restoring the original branch.\n\nA reader without a complete mental model for what \"git rebase\" does\ncould be very confused by this. One might think: does this mean that\ngit has been scribbling over the original branch, and this switch\nalmost completely cancels that but leaves the branch still\nscribbled-on?\n\nHow about something like:\n\n --keep-head::\n\tWhen aborting a rebase, do not check out the original branch\n\tbut leave the HEAD alone. This can be useful if you forgot\n\tabout a conflicted or interactive rebase in progress and have\n\tbeen committing on top of one of the commits being replayed.\n\n?\n\nAgh, \"git rebase --abort --keep-head\" feels a little too long to be\nmemorable. Still, hope that helps.\n\nCiao,\nJonathan\n"},{"id":"168936","messageId":"SNT124-W4764217DDF8E31B5155828C4780@phx.gbl","threadId":"27488","inReplyTo":"20110528230844.GA31498@elie","subject":"RE: [PATCH] rebase: learn --discard subcommand","fromName":"Tim Mazid","fromEmail":"timmazid@hotmail.com","sentAt":"2011-05-29T09:30:32Z","receivedAt":"2011-05-29T09:30:32Z","isPatch":true,"sender":{"key":"timmazid@hotmail.com","avatar":null},"body":"\n> Date: Sat, 28 May 2011 18:08:44 -0500\n> From: jrnieder@gmail.com\n> Martin von Zweigbergk wrote:\n> > Teach git-rebase the --discard subcommand, which is similar to\n> > --abort, but does not move back to the original branch. Suggest this\n> > new subcommand to the user where we currently suggest to delete\n> > $GIT_DIR/rebase-apply (or rebase-merge).\n>\n> Good idea.\n>\n> At first the name --discard made me think it was going to move back to\n> the original branch and discard the reset of the patch series being\n> rebased. Not sure what a better name would be, though.\n>\n> > --- a/Documentation/git-rebase.txt\n> > +++ b/Documentation/git-rebase.txt\n> > @@ -238,6 +238,9 @@ leave out at most one of A and B, in which case it defaults to HEAD.\n> [...]\n> > +--discard::\n> > + Abort the rebase operation without restoring the original branch.\n>\n> A reader without a complete mental model for what \"git rebase\" does\n> could be very confused by this. One might think: does this mean that\n> git has been scribbling over the original branch, and this switch\n> almost completely cancels that but leaves the branch still\n> scribbled-on?\n>\n> How about something like:\n>\n> --keep-head::\n> When aborting a rebase, do not check out the original branch\n> but leave the HEAD alone. This can be useful if you forgot\n> about a conflicted or interactive rebase in progress and have\n> been committing on top of one of the commits being replayed.\n>\n> ?\n>\n> Agh, \"git rebase --abort --keep-head\" feels a little too long to be\n> memorable. Still, hope that helps.\n\nHow about \"git rebase --stop\"?\n\nI think the word \"stop\" has the implication that you don't go\nanywhere, but also that you abort doing whatever it is you were\n(in this case, the rebase).\n\nAnd as I said before, I don't like the idea of changing the\nbehaviour of already existing (and widely used) commands and\noptions; even if, as in my case, they're not always used correctly.\n\n\nTim.\n\n() ascii ribbon campaign - against html e-mail\n/\\ www.asciiribbon.org - against proprietary attachments\n \t\t \t \t\t "},{"id":"168939","messageId":"alpine.DEB.2.00.1105290841400.28815@debian","threadId":"27488","inReplyTo":"BANLkTim-Wva018BFeTUPqZuiK02-X01XJQ@mail.gmail.com","subject":"Re: [PATCH] rebase: learn --discard subcommand","fromName":"Martin von Zweigbergk","fromEmail":"martin.von.zweigbergk@gmail.com","sentAt":"2011-05-29T12:50:19Z","receivedAt":"2011-05-29T12:50:19Z","isPatch":true,"sender":{"key":"martinvonz@gmail.com","avatar":"https://avatars.githubusercontent.com/u/891642?v=4"},"body":"On Sat, 28 May 2011, Ramkumar Ramachandra wrote:\n\n> > I used \"rm -r\" without -f to match how it is done in --abort, but\n> > maybe -f should be used? That is what we recommend to the end-user to\n> > use today.\n> \n> If you've verified that a rebase is already in progress, I don't see\n> the point of using '-f'. Otherwise, it should error out and say that\n> \"no rebase is in progress\", like the other command-line options\n> currently do.\n\nYep, it does verify that a rebase is in progress. I think rm without\n-f still asks the user to confirm if the file is read-only. I can't\nsee why that would happen, so maybe it's good to have the user confirm\nit it does happen.\n\n> > A difference from --abort is that --discard does not clear\n> > rerere. Need this be mentioned in the documentation?\n> \n> It depends on what you're expecting the user to do in this detached\n> HEAD state, no?\n\nThe subcommand will most likely be run when the user had forgotten the\ncurrent rebase and tries to start a new rebase and get's the message\nthat a rebase is already in progress. At this point, the user is not\nnecessarily in a detached HEAD state any more.\n\n/Martin\n"},{"id":"168940","messageId":"alpine.DEB.2.00.1105290850340.28815@debian","threadId":"27488","inReplyTo":"7vpqn2psjv.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] rebase: learn --discard subcommand","fromName":"Martin von Zweigbergk","fromEmail":"martin.von.zweigbergk@gmail.com","sentAt":"2011-05-29T13:14:50Z","receivedAt":"2011-05-29T13:14:50Z","isPatch":true,"sender":{"key":"martinvonz@gmail.com","avatar":"https://avatars.githubusercontent.com/u/891642?v=4"},"body":"On Sat, 28 May 2011, Junio C Hamano wrote:\n\n> Martin von Zweigbergk writes:\n> \n> > ... I think Junio then\n> > hinted that he sometimes wished that he could abort rebase without\n> > moving to anywhere else at all, which is what this patch implements.\n> \n> I am not opposed to this particular patch, but thinking about a bigger\n> picture, I am not sure if we want to solve it this way.\n> \n> We have multiple \"sequence\" operations that want to do things in multiple\n> steps, each of which can stop and give control back to the user, while\n> leaving some information in the .git directory for it to know where it was\n> when resuming. I think \"am\" knows about what \"rebase\" does (and\n> vice-versa) so it can detect an attempt to run it while \"rebase\" is in\n> still progress and refuse to continue to limit the damage, but if we have\n> N such \"sequence\" commands that want to refrain from interfering with each\n> other, and want to offer an advice to abort the in-progress operation\n> initiated by other commands, that would mean we would need N * N pieces of\n> logic to detect other's in-limbo state and offer advices, which would not\n> scale.\n\nMakes sense. I think someone once suggested to have a .git/inprogress\ndirectory that would contain some basic information that could be used\nto diagnose in a generic way what operation might be in progress.\n\n> A user who is given back the control from a \"sequence\" operation may be\n> confused either (1) immediately after such an event (often some sort of\n> merge conflict) or (2) much later after first abandoning the working tree\n> altogether and taking a walk and then coming back to continue working\n> while forgetting what he was doing. Such a user may want to say \"I know I\n> am in a strange state, give me a state that I can work from, at this point\n> I do not care about continuing what I was originally doing\". The user may\n> probably not know if \"git rebase\" was in progress or \"git cherry-pick\"\n> was.\n\nMaybe the recent patch [1] about adding information to git status\nabout any ongoing operation would help. I'm not sure, but I think I\nwould personally be a bit hesitant to cancel the current sequence\noperation without first checking what it was. OTOH, if I don't even\nremember starting a rebase operation, maybe knowing whether it was a\nrebase or an am operation might not help much. But if the message from\ngit status would actually say something like \"rebase in progress:\n[2/3] War on nbsp: a bit of retreat\", then that might help more in\nmaking a decision to cancel or not.\n\n\n [1] http://thread.gmane.org/gmane.comp.version-control.git/172919\n"},{"id":"168942","messageId":"m3r57hy68n.fsf@localhost.localdomain","threadId":"27488","inReplyTo":"alpine.DEB.2.00.1105290850340.28815@debian","subject":"Re: [PATCH] rebase: learn --discard subcommand","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2011-05-29T13:41:44Z","receivedAt":"2011-05-29T13:41:44Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Martin von Zweigbergk writes:\n\n> Maybe the recent patch [1] about adding information to git status\n> about any ongoing operation would help. I'm not sure, but I think I\n> would personally be a bit hesitant to cancel the current sequence\n> operation without first checking what it was. OTOH, if I don't even\n> remember starting a rebase operation, maybe knowing whether it was a\n> rebase or an am operation might not help much. But if the message from\n> git status would actually say something like \"rebase in progress:\n> [2/3] War on nbsp: a bit of retreat\", then that might help more in\n> making a decision to cancel or not.\n> \n> [1] http://thread.gmane.org/gmane.comp.version-control.git/172919\n\nSuch information could be not enough. I understand that \"git status\"\noutput space is limited, but it would be nice if e.g. \"git status -v\"\ndescribed current state in more detail:\n\n rebase in progress: [2/3] War on nbsp: a bit of retreat\"\n rebasing xx/foo --onto master~5\n\nIt would describe which branch were we rebasing, and on what commit\n(preferring for name-rev description to start from branch we were\nrebasing onto, if possible).\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"168945","messageId":"alpine.DEB.2.00.1105290916470.28815@debian","threadId":"27488","inReplyTo":"20110528230844.GA31498@elie","subject":"Re: [PATCH] rebase: learn --discard subcommand","fromName":"Martin von Zweigbergk","fromEmail":"martin.von.zweigbergk@gmail.com","sentAt":"2011-05-29T17:28:26Z","receivedAt":"2011-05-29T17:28:26Z","isPatch":true,"sender":{"key":"martinvonz@gmail.com","avatar":"https://avatars.githubusercontent.com/u/891642?v=4"},"body":"\nOn Sat, 28 May 2011, Jonathan Nieder wrote:\n\n> At first the name --discard made me think it was going to move back to\n> the original branch and discard the reset of the patch series being\n> rebased. Not sure what a better name would be, though.\n\nMaybe --stop as Tim suggested, but I think that also makes it sound\nlike we're dropping the rest of the patches. Other names would be\n--cancel or --forget.\n\n> > --- a/Documentation/git-rebase.txt\n> > +++ b/Documentation/git-rebase.txt\n> > @@ -238,6 +238,9 @@ leave out at most one of A and B, in which case it defaults to HEAD.\n> [...]\n> > +--discard::\n> > +\tAbort the rebase operation without restoring the original branch.\n> \n> A reader without a complete mental model for what \"git rebase\" does\n> could be very confused by this. One might think: does this mean that\n> git has been scribbling over the original branch, and this switch\n> almost completely cancels that but leaves the branch still\n> scribbled-on?\n\nThe --abort subcommand is currently described as \"Restore the original\nbranch and abort the rebase operation.\", so that would be in need of\nthe same clarification.\n\n> How about something like:\n> \n> --keep-head::\n> \tWhen aborting a rebase, do not check out the original branch\n> \tbut leave the HEAD alone. This can be useful if you forgot\n> \tabout a conflicted or interactive rebase in progress and have\n> \tbeen committing on top of one of the commits being replayed.\n> \n> ?\n\nThanks. I like it. Maybe with \"... or if you have moved to an\nunrelated commit\" or something like that be added to the end.\n\n> Agh, \"git rebase --abort --keep-head\" feels a little too long to be\n> memorable. Still, hope that helps.\n\nI intended --discard to be used _instead_ of --abort. Do you think it\nmakes more sense to have it as an option to --abort or was it just\nthat the word \"subcommand\" confused you? I meant it as \"subcommand of\ngit rebase\".\n\n\n/Martin\n"},{"id":"168948","messageId":"20110529185821.GA13751@elie","threadId":"27488","inReplyTo":"alpine.DEB.2.00.1105290916470.28815@debian","subject":"Re: [PATCH] rebase: learn --discard subcommand","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-05-29T18:58:21Z","receivedAt":"2011-05-29T18:58:21Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Martin von Zweigbergk wrote:\n\n> I intended --discard to be used _instead_ of --abort. Do you think it\n> makes more sense to have it as an option to --abort or was it just\n> that the word \"subcommand\" confused you? I meant it as \"subcommand of\n> git rebase\".\n\nI agree that --abort-keeping-head is nicer than --abort --keep-head.\nThe latter was just a little easier to document.\n\nSorry, I'm terrible at names. --forget, --discard, and --done have\nthe same problem of making the reader wonder what is going to be\nforgotten and what remembered.\n"},{"id":"168967","messageId":"4DE32138.4050104@alum.mit.edu","threadId":"27488","inReplyTo":"20110528230844.GA31498@elie","subject":"Re: [PATCH] rebase: learn --discard subcommand","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2011-05-30T04:46:48Z","receivedAt":"2011-05-30T04:46:48Z","isPatch":true,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 05/29/2011 01:08 AM, Jonathan Nieder wrote:\n> Agh, \"git rebase --abort --keep-head\" feels a little too long to be\n> memorable. Still, hope that helps.\n\nIt seems like the distinction is analogous to \"git reset --soft\", so maybe\n\n git rebase --abort --soft\n\n?\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"168968","messageId":"4DE3222F.6030604@alum.mit.edu","threadId":"27488","inReplyTo":"7vpqn2psjv.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] rebase: learn --discard subcommand","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2011-05-30T04:50:55Z","receivedAt":"2011-05-30T04:50:55Z","isPatch":true,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 05/28/2011 08:51 PM, Junio C Hamano wrote:\n> \"git reset --hard\" used to be such a command in simpler times. It removes\n> MERGE_HEAD unconditionally, so that a confused user can start from scratch\n> without having to worry about what was in progress. As a devil's advocate,\n> I am wondering if it is a good idea to simply teach \"reset --hard\" to also\n> remove any and all \"sequence\" cruft (.git/rebase-apply, .git/rebase-merge,\n> CHERRY_PICK_HEAD; we might have others I do not recall offhand) and be\n> done with it. It is a large hammer, but it is certainly the easiest to\n> explain and the simplest to understand way to get out of any troubles.\n\nIf it would be desirable to separate the resetting of the working tree\nfrom the resetting of any in-progress operation, perhaps \"git reset\n--abort\" (by analogy with \"git reset --abort\" etc) would be a possible\nspelling of the latter. To reset any in-progress operations *and* reset\nthe working tree, on could use \"git reset --hard --abort\".\n\nI strongly agree with another poster that it would be useful if \"git\nstatus\" would print information about in-progress operations.\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"168969","messageId":"buolixokcic.fsf@dhlpc061.dev.necel.com","threadId":"27488","inReplyTo":"20110528230844.GA31498@elie","subject":"Re: [PATCH] rebase: learn --discard subcommand","fromName":"Miles Bader","fromEmail":"miles@gnu.org","sentAt":"2011-05-30T05:01:31Z","receivedAt":"2011-05-30T05:01:31Z","isPatch":true,"sender":{"key":"miles@gnu.org","avatar":"https://gravatar.com/avatar/01069b69593af7bff28e2f97afeb3644ae6fe2f5f56cb3a8cf34c5fb8c36efe5?d=mp&s=160"},"body":"Jonathan Nieder writes:\n> Agh, \"git rebase --abort --keep-head\" feels a little too long to be\n> memorable. Still, hope that helps.\n\n\"--abort --stay\"...?\n\n-miles\n\n-- \nCat, n. A soft, indestructible automaton provided by nature to be kicked when\nthings go wrong in the domestic circle.\n"},{"id":"168970","messageId":"20110530051434.GA3723@Imperial-SD-Longsword","threadId":"27488","inReplyTo":"4DE32138.4050104@alum.mit.edu","subject":"Re: [PATCH] rebase: learn --discard subcommand","fromName":"Tim Mazid","fromEmail":"timmazid@hotmail.com","sentAt":"2011-05-30T05:14:35Z","receivedAt":"2011-05-30T05:14:35Z","isPatch":true,"sender":{"key":"timmazid@hotmail.com","avatar":null},"body":"On Mon, May 30, 2011 at 06:46:48AM +0200, Michael Haggerty wrote:\n> On 05/29/2011 01:08 AM, Jonathan Nieder wrote:\n> > Agh, \"git rebase --abort --keep-head\" feels a little too long to be\n> > memorable. Still, hope that helps.\n> \n> It seems like the distinction is analogous to \"git reset --soft\", so maybe\n> \n> git rebase --abort --soft\n\nWell, the only problem with that is the \"--soft\" option refers to the\n\"reset\" command given to git, whereas in your proposed syntax, the\n\"--soft\" option refers to the _other_ option, \"--abort\".\n\nThis may seem a little nit-picky, but such a difference could lead to\nconfusion. Perhaps \"--soft-abort\" or \"--soft-abort\" would be better? A\nsingle option to the \"git rebase\" command rather than a \"sub-option\"\ngiven to another option.\n\nIt just seems to me that all the git commands work this way; \"git\ncommand --options-to-command\". An option to another option just seems\ntoo confusing.\n\nOf course, there's the floodgate problem; once you have options to\noptions, are you going to have options to options to options, ad\ninfinitum?\n\n-- \nTim\n\n() ascii ribbon campaign - against html e-mail\n/\\ www.asciiribbon.org - against proprietary attachments\n"},{"id":"168982","messageId":"4DE358D5.9010900@alum.mit.edu","threadId":"27488","inReplyTo":"20110530051434.GA3723@Imperial-SD-Longsword","subject":"Re: [PATCH] rebase: learn --discard subcommand","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2011-05-30T08:44:05Z","receivedAt":"2011-05-30T08:44:05Z","isPatch":true,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 05/30/2011 07:14 AM, Tim Mazid wrote:\n> On Mon, May 30, 2011 at 06:46:48AM +0200, Michael Haggerty wrote:\n>> On 05/29/2011 01:08 AM, Jonathan Nieder wrote:\n>>> Agh, \"git rebase --abort --keep-head\" feels a little too long to be\n>>> memorable. Still, hope that helps.\n>>\n>> It seems like the distinction is analogous to \"git reset --soft\", so maybe\n>>\n>> git rebase --abort --soft\n> \n> Well, the only problem with that is the \"--soft\" option refers to the\n> \"reset\" command given to git, whereas in your proposed syntax, the\n> \"--soft\" option refers to the _other_ option, \"--abort\".\n> \n> This may seem a little nit-picky, but such a difference could lead to\n> confusion. Perhaps \"--soft-abort\" or \"--soft-abort\" would be better? A\n> single option to the \"git rebase\" command rather than a \"sub-option\"\n> given to another option.\n\nTo be even more nit-picky :-), --abort (and --continue) are really\nsubcommands of rebase. The fact that they are implemented as options is\nthe original source of the inconsistency. Of course this cannot be\nchanged because \"git rebase abort\" already has a different meaning.\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"}]}