# [PATCH] rebase: learn --discard subcommand 17 messages from 2011-05-28 to 2011-05-30. Participants: Martin von Zweigbergk, Ramkumar Ramachandra, Junio C Hamano, Tim Mazid, Jonathan Nieder, Jakub Narebski, Michael Haggerty, Miles Bader. Thread: https://gitlist.dev/t/27488 ## Martin von Zweigbergk, 2011-05-28 02:58 Subject: [PATCH] rebase: learn --discard subcommand Message-ID: <1306551495-26685-1-git-send-email-martin.von.zweigbergk@gmail.com> URL: https://gitlist.dev/e/1306551495-26685-1-git-send-email-martin.von.zweigbergk%40gmail.com ``` Teach git-rebase the --discard subcommand, which is similar to --abort, but does not move back to the original branch. Suggest this new subcommand to the user where we currently suggest to delete $GIT_DIR/rebase-apply (or rebase-merge). Signed-off-by: Martin von Zweigbergk --- A long time ago I said I wished that 'git rebase --abort' would move back to the where HEAD was when the rebase was initiated, instead of moving back to the branch that was about to be rebased (which may be different for "git rebase $upstream $branch"). I think Junio then hinted that he sometimes wished that he could abort rebase without moving to anywhere else at all, which is what this patch implements. I don't feel strongly about this patch, but I would probably also use this subcommand once in a while. However, maybe the greatest value in it is that we don't have to tell users to mess with the .git directory? I used "rm -r" without -f to match how it is done in --abort, but maybe -f should be used? That is what we recommend to the end-user to use today. A difference from --abort is that --discard does not clear rerere. Need this be mentioned in the documentation? I have not been involved in Ramkumar's work on the sequencer to know if and how this might impact it. Documentation/git-rebase.txt | 5 ++++- git-rebase.sh | 17 +++++++++++------ 2 files changed, 15 insertions(+), 7 deletions(-) diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt index 9a075bc..e841c21 100644 --- a/Documentation/git-rebase.txt +++ b/Documentation/git-rebase.txt @@ -13,7 +13,7 @@ SYNOPSIS 'git rebase' [-i | --interactive] [options] --onto --root [] -'git rebase' --continue | --skip | --abort +'git rebase' --continue | --skip | --abort | --discard DESCRIPTION ----------- @@ -238,6 +238,9 @@ leave out at most one of A and B, in which case it defaults to HEAD. --skip:: Restart the rebasing process by skipping the current patch. +--discard:: + Abort the rebase operation without restoring the original branch. + -m:: --merge:: Use merging strategies to rebase. When the recursive (default) merge diff --git a/git-rebase.sh b/git-rebase.sh index 7a54bfc..befee92 100755 --- a/git-rebase.sh +++ b/git-rebase.sh @@ -32,7 +32,7 @@ OPTIONS_KEEPDASHDASH= OPTIONS_SPEC="\ git rebase [-i] [options] [--onto ] [] [] git rebase [-i] [options] --onto --root [] -git-rebase [-i] --continue | --abort | --skip +git-rebase [-i] --continue | --abort | --skip | --discard -- Available options are v,verbose! display a diffstat of what changed upstream @@ -60,6 +60,7 @@ C=! passed to 'git apply' continue! continue rebasing process abort! abort rebasing process and restore original branch skip! skip current patch and continue rebasing process +discard! abort rebasing process, but do not restore original branch " . git-sh-setup set_reflog_action rebase @@ -93,7 +94,7 @@ in_progress= type= # One of {"$GIT_DIR"/rebase-apply, "$GIT_DIR"/rebase-merge} state_dir= -# One of {'', continue, skip, abort}, as parsed from command line +# One of {'', continue, skip, abort, discard}, as parsed from command line action= preserve_merges= autosquash= @@ -206,7 +207,7 @@ do --verify) ok_to_skip_pre_rebase= ;; - --continue|--skip|--abort) + --continue|--skip|--abort|--discard) test $total_argc -eq 2 || usage action=${1##--} ;; @@ -340,6 +341,10 @@ abort) rm -r "$state_dir" exit ;; +discard) + rm -r "$state_dir" + exit + ;; esac # Make sure no rebase is in progress @@ -349,9 +354,9 @@ then It seems that there is already a '"${state_dir##*/}"' directory, and I wonder if you are in the middle of another rebase. If that is the case, please try - git rebase (--continue | --abort | --skip) -If that is not the case, please - rm -fr '"$state_dir"' + git rebase (--continue | --abort | --skip | --discard) +If that is not the case, please run + git rebase --discard and run me again. I am stopping in case you still have something valuable there.' fi -- 1.7.4.79.gcbe20 ``` ## Ramkumar Ramachandra, 2011-05-28 13:15 Subject: Re: [PATCH] rebase: learn --discard subcommand Message-ID: URL: https://gitlist.dev/e/BANLkTim-Wva018BFeTUPqZuiK02-X01XJQ%40mail.gmail.com In-Reply-To: <1306551495-26685-1-git-send-email-martin.von.zweigbergk@gmail.com> ``` Hi Martin, Martin von Zweigbergk writes: > A long time ago I said I wished that 'git rebase --abort' would move > back to the where HEAD was when the rebase was initiated, instead of > moving back to the branch that was about to be rebased (which may be > different for "git rebase $upstream $branch"). I think Junio then > hinted that he sometimes wished that he could abort rebase without > moving to anywhere else at all, which is what this patch implements. I > don't feel strongly about this patch, but I would probably also use > this subcommand once in a while. However, maybe the greatest value in > it is that we don't have to tell users to mess with the .git > directory? Interesting. Yes, I usually remove the state file by hand too. In view of "git rebase --interactive" being a porcelain command, I don't know if it's alright to drop the user into a detached HEAD state. > I used "rm -r" without -f to match how it is done in --abort, but > maybe -f should be used? That is what we recommend to the end-user to > use today. If you've verified that a rebase is already in progress, I don't see the point of using '-f'. Otherwise, it should error out and say that "no rebase is in progress", like the other command-line options currently do. > A difference from --abort is that --discard does not clear > rerere. Need this be mentioned in the documentation? It depends on what you're expecting the user to do in this detached HEAD state, no? > I have not been involved in Ramkumar's work on the sequencer to know > if and how this might impact it. It'll have no impact on the Sequencer work. Thanks. -- Ram ``` ## Junio C Hamano, 2011-05-28 18:51 Subject: Re: [PATCH] rebase: learn --discard subcommand Message-ID: <7vpqn2psjv.fsf@alter.siamese.dyndns.org> URL: https://gitlist.dev/e/7vpqn2psjv.fsf%40alter.siamese.dyndns.org In-Reply-To: <1306551495-26685-1-git-send-email-martin.von.zweigbergk@gmail.com> ``` Martin von Zweigbergk writes: > ... I think Junio then > hinted that he sometimes wished that he could abort rebase without > moving to anywhere else at all, which is what this patch implements. I am not opposed to this particular patch, but thinking about a bigger picture, I am not sure if we want to solve it this way. We have multiple "sequence" operations that want to do things in multiple steps, each of which can stop and give control back to the user, while leaving some information in the .git directory for it to know where it was when resuming. I think "am" knows about what "rebase" does (and vice-versa) so it can detect an attempt to run it while "rebase" is in still progress and refuse to continue to limit the damage, but if we have N such "sequence" commands that want to refrain from interfering with each other, and want to offer an advice to abort the in-progress operation initiated by other commands, that would mean we would need N * N pieces of logic to detect other's in-limbo state and offer advices, which would not scale. A user who is given back the control from a "sequence" operation may be confused either (1) immediately after such an event (often some sort of merge conflict) or (2) much later after first abandoning the working tree altogether and taking a walk and then coming back to continue working while forgetting what he was doing. Such a user may want to say "I know I am in a strange state, give me a state that I can work from, at this point I do not care about continuing what I was originally doing". The user may probably not know if "git rebase" was in progress or "git cherry-pick" was. "git reset --hard" used to be such a command in simpler times. It removes MERGE_HEAD unconditionally, so that a confused user can start from scratch without having to worry about what was in progress. As a devil's advocate, I am wondering if it is a good idea to simply teach "reset --hard" to also remove any and all "sequence" cruft (.git/rebase-apply, .git/rebase-merge, CHERRY_PICK_HEAD; we might have others I do not recall offhand) and be done with it. It is a large hammer, but it is certainly the easiest to explain and the simplest to understand way to get out of any troubles. ``` ## Tim Mazid, 2011-05-28 20:26 Subject: RE: [PATCH] rebase: learn --discard subcommand Message-ID: URL: https://gitlist.dev/e/SNT124-W247D44D043F692CA06747EC4790%40phx.gbl In-Reply-To: <7vpqn2psjv.fsf@alter.siamese.dyndns.org> ``` > From: gitster@pobox.com > Date: Sat, 28 May 2011 11:51:32 -0700 > > Martin von Zweigbergk writes: > > > ... I think Junio then > > hinted that he sometimes wished that he could abort rebase without > > moving to anywhere else at all, which is what this patch implements. > > I am not opposed to this particular patch, but thinking about a bigger > picture, I am not sure if we want to solve it this way. > > We have multiple "sequence" operations that want to do things in multiple > steps, each of which can stop and give control back to the user, while > leaving some information in the .git directory for it to know where it was > when resuming. I think "am" knows about what "rebase" does (and > vice-versa) so it can detect an attempt to run it while "rebase" is in > still progress and refuse to continue to limit the damage, but if we have > N such "sequence" commands that want to refrain from interfering with each > other, and want to offer an advice to abort the in-progress operation > initiated by other commands, that would mean we would need N * N pieces of > logic to detect other's in-limbo state and offer advices, which would not > scale. > > A user who is given back the control from a "sequence" operation may be > confused either (1) immediately after such an event (often some sort of > merge conflict) or (2) much later after first abandoning the working tree > altogether and taking a walk and then coming back to continue working > while forgetting what he was doing. Such a user may want to say "I know I > am in a strange state, give me a state that I can work from, at this point > I do not care about continuing what I was originally doing". The user may > probably not know if "git rebase" was in progress or "git cherry-pick" > was. > > "git reset --hard" used to be such a command in simpler times. It removes > MERGE_HEAD unconditionally, so that a confused user can start from scratch > without having to worry about what was in progress. As a devil's advocate, > I am wondering if it is a good idea to simply teach "reset --hard" to also > remove any and all "sequence" cruft (.git/rebase-apply, .git/rebase-merge, > CHERRY_PICK_HEAD; we might have others I do not recall offhand) and be > done with it. It is a large hammer, but it is certainly the easiest to > explain and the simplest to understand way to get out of any troubles. I'd just like to say that I sometime use "git reset --hard" in the middle of a "git rebase" when I want to get rid of some changes completely. Now, I'm not saying that this is the best way of doing it ("git checkout --" is probably far superior?), but I daresay that there are some users out there who will be surprised by the new behaviour of "git reset --hard". Having said that, before I knew that "git reset --hard" could be used in the middle of a rebase without aborting the reset, I did try to use it to abort the rebase, because, as you said, it seems to be "uh oh" button in git. So it's a bit of a toss-up really. Having said that, I would support making "reset --hard" abort rebases, on the condition that there are some _big_ warnings somewhere about the change in behaviour. Tim. () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org    - against proprietary attachments ``` ## Jonathan Nieder, 2011-05-28 22:50 Subject: Re: [PATCH] rebase: learn --discard subcommand Message-ID: <20110528225046.GA31449@elie> URL: https://gitlist.dev/e/20110528225046.GA31449%40elie In-Reply-To: ``` Hi, Tim Mazid wrote: > I'd just like to say that I sometime use "git reset --hard" in the middle > of a "git rebase" when I want to get rid of some changes completely. > Now, I'm not saying that this is the best way of doing it ("git checkout --" > is probably far superior?) . "git checkout -- ." to discard unadded changes . "git checkout HEAD -- ." to discard uncommitted changes . "git reset --keep HEAD^" to work against a different commit . "git reset --merge" to discard a merge resolution in progress While I also would be happy to see "git reset --hard" to abort am/rebase, I see two problems, one with an obvious solution, the other not: 1. It would be a big change in behavior that directly goes against muscle memory, as you mentioned. This part could be mitigated by providing "undo" functionality (e.g., renaming the .git/rebase-merge directory instead of deleting it) and printing advice including a command that gets the sequencer state back. 2. It does not help people like me who are fearful about scribbling over accidentally unstaged or uncommitted changes. This could be mitigated by also providing forget-sequence functionality through separate commands like "git rebase --discard". ``` ## Jonathan Nieder, 2011-05-28 23:08 Subject: Re: [PATCH] rebase: learn --discard subcommand Message-ID: <20110528230844.GA31498@elie> URL: https://gitlist.dev/e/20110528230844.GA31498%40elie In-Reply-To: <1306551495-26685-1-git-send-email-martin.von.zweigbergk@gmail.com> ``` Hi, Martin von Zweigbergk wrote: > Teach git-rebase the --discard subcommand, which is similar to > --abort, but does not move back to the original branch. Suggest this > new subcommand to the user where we currently suggest to delete > $GIT_DIR/rebase-apply (or rebase-merge). Good idea. At first the name --discard made me think it was going to move back to the original branch and discard the reset of the patch series being rebased. Not sure what a better name would be, though. > --- a/Documentation/git-rebase.txt > +++ b/Documentation/git-rebase.txt > @@ -238,6 +238,9 @@ leave out at most one of A and B, in which case it defaults to HEAD. [...] > +--discard:: > + Abort the rebase operation without restoring the original branch. A reader without a complete mental model for what "git rebase" does could be very confused by this. One might think: does this mean that git has been scribbling over the original branch, and this switch almost completely cancels that but leaves the branch still scribbled-on? How about something like: --keep-head:: When aborting a rebase, do not check out the original branch but leave the HEAD alone. This can be useful if you forgot about a conflicted or interactive rebase in progress and have been committing on top of one of the commits being replayed. ? Agh, "git rebase --abort --keep-head" feels a little too long to be memorable. Still, hope that helps. Ciao, Jonathan ``` ## Tim Mazid, 2011-05-29 09:30 Subject: RE: [PATCH] rebase: learn --discard subcommand Message-ID: URL: https://gitlist.dev/e/SNT124-W4764217DDF8E31B5155828C4780%40phx.gbl In-Reply-To: <20110528230844.GA31498@elie> ``` > Date: Sat, 28 May 2011 18:08:44 -0500 > From: jrnieder@gmail.com > Martin von Zweigbergk wrote: > > Teach git-rebase the --discard subcommand, which is similar to > > --abort, but does not move back to the original branch. Suggest this > > new subcommand to the user where we currently suggest to delete > > $GIT_DIR/rebase-apply (or rebase-merge). > > Good idea. > > At first the name --discard made me think it was going to move back to > the original branch and discard the reset of the patch series being > rebased. Not sure what a better name would be, though. > > > --- a/Documentation/git-rebase.txt > > +++ b/Documentation/git-rebase.txt > > @@ -238,6 +238,9 @@ leave out at most one of A and B, in which case it defaults to HEAD. > [...] > > +--discard:: > > + Abort the rebase operation without restoring the original branch. > > A reader without a complete mental model for what "git rebase" does > could be very confused by this. One might think: does this mean that > git has been scribbling over the original branch, and this switch > almost completely cancels that but leaves the branch still > scribbled-on? > > How about something like: > > --keep-head:: > When aborting a rebase, do not check out the original branch > but leave the HEAD alone. This can be useful if you forgot > about a conflicted or interactive rebase in progress and have > been committing on top of one of the commits being replayed. > > ? > > Agh, "git rebase --abort --keep-head" feels a little too long to be > memorable. Still, hope that helps. How about "git rebase --stop"? I think the word "stop" has the implication that you don't go anywhere, but also that you abort doing whatever it is you were (in this case, the rebase). And as I said before, I don't like the idea of changing the behaviour of already existing (and widely used) commands and options; even if, as in my case, they're not always used correctly. Tim. () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments ``` ## Martin von Zweigbergk, 2011-05-29 12:50 Subject: Re: [PATCH] rebase: learn --discard subcommand Message-ID: URL: https://gitlist.dev/e/alpine.DEB.2.00.1105290841400.28815%40debian In-Reply-To: ``` On Sat, 28 May 2011, Ramkumar Ramachandra wrote: > > I used "rm -r" without -f to match how it is done in --abort, but > > maybe -f should be used? That is what we recommend to the end-user to > > use today. > > If you've verified that a rebase is already in progress, I don't see > the point of using '-f'. Otherwise, it should error out and say that > "no rebase is in progress", like the other command-line options > currently do. Yep, it does verify that a rebase is in progress. I think rm without -f still asks the user to confirm if the file is read-only. I can't see why that would happen, so maybe it's good to have the user confirm it it does happen. > > A difference from --abort is that --discard does not clear > > rerere. Need this be mentioned in the documentation? > > It depends on what you're expecting the user to do in this detached > HEAD state, no? The subcommand will most likely be run when the user had forgotten the current rebase and tries to start a new rebase and get's the message that a rebase is already in progress. At this point, the user is not necessarily in a detached HEAD state any more. /Martin ``` ## Martin von Zweigbergk, 2011-05-29 13:14 Subject: Re: [PATCH] rebase: learn --discard subcommand Message-ID: URL: https://gitlist.dev/e/alpine.DEB.2.00.1105290850340.28815%40debian In-Reply-To: <7vpqn2psjv.fsf@alter.siamese.dyndns.org> ``` On Sat, 28 May 2011, Junio C Hamano wrote: > Martin von Zweigbergk writes: > > > ... I think Junio then > > hinted that he sometimes wished that he could abort rebase without > > moving to anywhere else at all, which is what this patch implements. > > I am not opposed to this particular patch, but thinking about a bigger > picture, I am not sure if we want to solve it this way. > > We have multiple "sequence" operations that want to do things in multiple > steps, each of which can stop and give control back to the user, while > leaving some information in the .git directory for it to know where it was > when resuming. I think "am" knows about what "rebase" does (and > vice-versa) so it can detect an attempt to run it while "rebase" is in > still progress and refuse to continue to limit the damage, but if we have > N such "sequence" commands that want to refrain from interfering with each > other, and want to offer an advice to abort the in-progress operation > initiated by other commands, that would mean we would need N * N pieces of > logic to detect other's in-limbo state and offer advices, which would not > scale. Makes sense. I think someone once suggested to have a .git/inprogress directory that would contain some basic information that could be used to diagnose in a generic way what operation might be in progress. > A user who is given back the control from a "sequence" operation may be > confused either (1) immediately after such an event (often some sort of > merge conflict) or (2) much later after first abandoning the working tree > altogether and taking a walk and then coming back to continue working > while forgetting what he was doing. Such a user may want to say "I know I > am in a strange state, give me a state that I can work from, at this point > I do not care about continuing what I was originally doing". The user may > probably not know if "git rebase" was in progress or "git cherry-pick" > was. Maybe the recent patch [1] about adding information to git status about any ongoing operation would help. I'm not sure, but I think I would personally be a bit hesitant to cancel the current sequence operation without first checking what it was. OTOH, if I don't even remember starting a rebase operation, maybe knowing whether it was a rebase or an am operation might not help much. But if the message from git status would actually say something like "rebase in progress: [2/3] War on nbsp: a bit of retreat", then that might help more in making a decision to cancel or not. [1] http://thread.gmane.org/gmane.comp.version-control.git/172919 ``` ## Jakub Narebski, 2011-05-29 13:41 Subject: Re: [PATCH] rebase: learn --discard subcommand Message-ID: URL: https://gitlist.dev/e/m3r57hy68n.fsf%40localhost.localdomain In-Reply-To: ``` Martin von Zweigbergk writes: > Maybe the recent patch [1] about adding information to git status > about any ongoing operation would help. I'm not sure, but I think I > would personally be a bit hesitant to cancel the current sequence > operation without first checking what it was. OTOH, if I don't even > remember starting a rebase operation, maybe knowing whether it was a > rebase or an am operation might not help much. But if the message from > git status would actually say something like "rebase in progress: > [2/3] War on nbsp: a bit of retreat", then that might help more in > making a decision to cancel or not. > > [1] http://thread.gmane.org/gmane.comp.version-control.git/172919 Such information could be not enough. I understand that "git status" output space is limited, but it would be nice if e.g. "git status -v" described current state in more detail: rebase in progress: [2/3] War on nbsp: a bit of retreat" rebasing xx/foo --onto master~5 It would describe which branch were we rebasing, and on what commit (preferring for name-rev description to start from branch we were rebasing onto, if possible). -- Jakub Narebski Poland ShadeHawk on #git ``` ## Martin von Zweigbergk, 2011-05-29 17:28 Subject: Re: [PATCH] rebase: learn --discard subcommand Message-ID: URL: https://gitlist.dev/e/alpine.DEB.2.00.1105290916470.28815%40debian In-Reply-To: <20110528230844.GA31498@elie> ``` On Sat, 28 May 2011, Jonathan Nieder wrote: > At first the name --discard made me think it was going to move back to > the original branch and discard the reset of the patch series being > rebased. Not sure what a better name would be, though. Maybe --stop as Tim suggested, but I think that also makes it sound like we're dropping the rest of the patches. Other names would be --cancel or --forget. > > --- a/Documentation/git-rebase.txt > > +++ b/Documentation/git-rebase.txt > > @@ -238,6 +238,9 @@ leave out at most one of A and B, in which case it defaults to HEAD. > [...] > > +--discard:: > > + Abort the rebase operation without restoring the original branch. > > A reader without a complete mental model for what "git rebase" does > could be very confused by this. One might think: does this mean that > git has been scribbling over the original branch, and this switch > almost completely cancels that but leaves the branch still > scribbled-on? The --abort subcommand is currently described as "Restore the original branch and abort the rebase operation.", so that would be in need of the same clarification. > How about something like: > > --keep-head:: > When aborting a rebase, do not check out the original branch > but leave the HEAD alone. This can be useful if you forgot > about a conflicted or interactive rebase in progress and have > been committing on top of one of the commits being replayed. > > ? Thanks. I like it. Maybe with "... or if you have moved to an unrelated commit" or something like that be added to the end. > Agh, "git rebase --abort --keep-head" feels a little too long to be > memorable. Still, hope that helps. I intended --discard to be used _instead_ of --abort. Do you think it makes more sense to have it as an option to --abort or was it just that the word "subcommand" confused you? I meant it as "subcommand of git rebase". /Martin ``` ## Jonathan Nieder, 2011-05-29 18:58 Subject: Re: [PATCH] rebase: learn --discard subcommand Message-ID: <20110529185821.GA13751@elie> URL: https://gitlist.dev/e/20110529185821.GA13751%40elie In-Reply-To: ``` Martin von Zweigbergk wrote: > I intended --discard to be used _instead_ of --abort. Do you think it > makes more sense to have it as an option to --abort or was it just > that the word "subcommand" confused you? I meant it as "subcommand of > git rebase". I agree that --abort-keeping-head is nicer than --abort --keep-head. The latter was just a little easier to document. Sorry, I'm terrible at names. --forget, --discard, and --done have the same problem of making the reader wonder what is going to be forgotten and what remembered. ``` ## Michael Haggerty, 2011-05-30 04:46 Subject: Re: [PATCH] rebase: learn --discard subcommand Message-ID: <4DE32138.4050104@alum.mit.edu> URL: https://gitlist.dev/e/4DE32138.4050104%40alum.mit.edu In-Reply-To: <20110528230844.GA31498@elie> ``` On 05/29/2011 01:08 AM, Jonathan Nieder wrote: > Agh, "git rebase --abort --keep-head" feels a little too long to be > memorable. Still, hope that helps. It seems like the distinction is analogous to "git reset --soft", so maybe git rebase --abort --soft ? Michael -- Michael Haggerty mhagger@alum.mit.edu http://softwareswirl.blogspot.com/ ``` ## Michael Haggerty, 2011-05-30 04:50 Subject: Re: [PATCH] rebase: learn --discard subcommand Message-ID: <4DE3222F.6030604@alum.mit.edu> URL: https://gitlist.dev/e/4DE3222F.6030604%40alum.mit.edu In-Reply-To: <7vpqn2psjv.fsf@alter.siamese.dyndns.org> ``` On 05/28/2011 08:51 PM, Junio C Hamano wrote: > "git reset --hard" used to be such a command in simpler times. It removes > MERGE_HEAD unconditionally, so that a confused user can start from scratch > without having to worry about what was in progress. As a devil's advocate, > I am wondering if it is a good idea to simply teach "reset --hard" to also > remove any and all "sequence" cruft (.git/rebase-apply, .git/rebase-merge, > CHERRY_PICK_HEAD; we might have others I do not recall offhand) and be > done with it. It is a large hammer, but it is certainly the easiest to > explain and the simplest to understand way to get out of any troubles. If it would be desirable to separate the resetting of the working tree from the resetting of any in-progress operation, perhaps "git reset --abort" (by analogy with "git reset --abort" etc) would be a possible spelling of the latter. To reset any in-progress operations *and* reset the working tree, on could use "git reset --hard --abort". I strongly agree with another poster that it would be useful if "git status" would print information about in-progress operations. Michael -- Michael Haggerty mhagger@alum.mit.edu http://softwareswirl.blogspot.com/ ``` ## Miles Bader, 2011-05-30 05:01 Subject: Re: [PATCH] rebase: learn --discard subcommand Message-ID: URL: https://gitlist.dev/e/buolixokcic.fsf%40dhlpc061.dev.necel.com In-Reply-To: <20110528230844.GA31498@elie> ``` Jonathan Nieder writes: > Agh, "git rebase --abort --keep-head" feels a little too long to be > memorable. Still, hope that helps. "--abort --stay"...? -miles -- Cat, n. A soft, indestructible automaton provided by nature to be kicked when things go wrong in the domestic circle. ``` ## Tim Mazid, 2011-05-30 05:14 Subject: Re: [PATCH] rebase: learn --discard subcommand Message-ID: <20110530051434.GA3723@Imperial-SD-Longsword> URL: https://gitlist.dev/e/20110530051434.GA3723%40Imperial-SD-Longsword In-Reply-To: <4DE32138.4050104@alum.mit.edu> ``` On Mon, May 30, 2011 at 06:46:48AM +0200, Michael Haggerty wrote: > On 05/29/2011 01:08 AM, Jonathan Nieder wrote: > > Agh, "git rebase --abort --keep-head" feels a little too long to be > > memorable. Still, hope that helps. > > It seems like the distinction is analogous to "git reset --soft", so maybe > > git rebase --abort --soft Well, the only problem with that is the "--soft" option refers to the "reset" command given to git, whereas in your proposed syntax, the "--soft" option refers to the _other_ option, "--abort". This may seem a little nit-picky, but such a difference could lead to confusion. Perhaps "--soft-abort" or "--soft-abort" would be better? A single option to the "git rebase" command rather than a "sub-option" given to another option. It just seems to me that all the git commands work this way; "git command --options-to-command". An option to another option just seems too confusing. Of course, there's the floodgate problem; once you have options to options, are you going to have options to options to options, ad infinitum? -- Tim () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments ``` ## Michael Haggerty, 2011-05-30 08:44 Subject: Re: [PATCH] rebase: learn --discard subcommand Message-ID: <4DE358D5.9010900@alum.mit.edu> URL: https://gitlist.dev/e/4DE358D5.9010900%40alum.mit.edu In-Reply-To: <20110530051434.GA3723@Imperial-SD-Longsword> ``` On 05/30/2011 07:14 AM, Tim Mazid wrote: > On Mon, May 30, 2011 at 06:46:48AM +0200, Michael Haggerty wrote: >> On 05/29/2011 01:08 AM, Jonathan Nieder wrote: >>> Agh, "git rebase --abort --keep-head" feels a little too long to be >>> memorable. Still, hope that helps. >> >> It seems like the distinction is analogous to "git reset --soft", so maybe >> >> git rebase --abort --soft > > Well, the only problem with that is the "--soft" option refers to the > "reset" command given to git, whereas in your proposed syntax, the > "--soft" option refers to the _other_ option, "--abort". > > This may seem a little nit-picky, but such a difference could lead to > confusion. Perhaps "--soft-abort" or "--soft-abort" would be better? A > single option to the "git rebase" command rather than a "sub-option" > given to another option. To be even more nit-picky :-), --abort (and --continue) are really subcommands of rebase. The fact that they are implemented as options is the original source of the inconsistency. Of course this cannot be changed because "git rebase abort" already has a different meaning. Michael -- Michael Haggerty mhagger@alum.mit.edu http://softwareswirl.blogspot.com/ ```