{"thread":{"id":"26722","subject":"[RFD] make rebase abort to original branch, not rebased branch","startedAt":"2011-03-13T03:58:20Z","lastAt":"2011-03-13T15:27:43Z","messageCount":5,"participants":["Martin von Zweigbergk","Junio C Hamano","Alexander Miseler"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"163278","messageId":"alpine.DEB.2.00.1103122253560.15442@debian","threadId":"26722","inReplyTo":null,"subject":"[RFD] make rebase abort to original branch, not rebased branch","fromName":"Martin von Zweigbergk","fromEmail":"martin.von.zweigbergk@gmail.com","sentAt":"2011-03-13T03:58:20Z","receivedAt":"2011-03-13T03:58:20Z","isPatch":false,"sender":{"key":"martinvonz@gmail.com","avatar":"https://avatars.githubusercontent.com/u/891642?v=4"},"body":"When git rebase is aborted, it will return the HEAD to the rebased\nbranch (which has not moved). If the current branch is \"topic\" and a\nrun of \"git rebase master\" is aborted, \"topic\" is therefore checked\nout, which is both what I expect and what I want. When the\ntwo-argument version of git rebase is used, as in \"git rebase master\ntopic\", and then aborted, \"topic\" will be checked out. This is not\nwhat I would expect, although I'm aware of it by now, and usually not\nwhat I want. I would expect to be returned to the branch/commit that\nwas checked out when I started \"git rebase master topic\".\n\nIn most cases, this is just a small annoyance, since it's usually\nquick and easy to manually switch back to the original\nbranch. However, I have run into at least two cases where it has been\na bit more annoying:\n\n 1. When on a detached HEAD and running \"git rebase HEAD topic\", if\n    you abort the rebase, you will have to look up the old commit in\n    the reflog.\n\n 2. I once was rebasing many old branches, mostly to see which ones\n    could be rebased without conflicts. The project I was working on\n    was pretty big and a lot had changed since those old branches were\n    created. If a \"new\" branch is currently checked out and \"git\n    rebase master old-branch\" is run and causes conflicts, the old\n    branch would be checked out. In my case, this would take 5-10\n    seconds. Since Junio improved rebase in 0cb0664 (rebase [--onto O]\n    A B: omit needless checkout, 2008-03-15), there will be no\n    checkouts of any \"old\" commit in the successful case, so it's a\n    shame that it has to happen in the unsuccessful case when the\n    rebase is aborted.\n\nAre there valid cases where the current behavior is bettter?\n\nI suppose we can not just change the current behavior due to backward\ncompatibility constraints. We could introduce a configuration\nvariable, of we could perhaps change it in 1.8.0. Maybe the problem is\nnot big enough to do either...\n\n\n/Martin\n"},{"id":"163281","messageId":"7vmxkzijpt.fsf@alter.siamese.dyndns.org","threadId":"26722","inReplyTo":"alpine.DEB.2.00.1103122253560.15442@debian","subject":"Re: [RFD] make rebase abort to original branch, not rebased branch","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-03-13T07:05:18Z","receivedAt":"2011-03-13T07:05:18Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Martin von Zweigbergk <martin.von.zweigbergk@gmail.com> writes:\n\n> In most cases, this is just a small annoyance, since it's usually\n> quick and easy to manually switch back to the original\n> branch. However, I have run into at least two cases where it has been\n> a bit more annoying:\n>\n>  1. When on a detached HEAD and running \"git rebase HEAD topic\", if\n>     you abort the rebase, you will have to look up the old commit in\n>     the reflog.\n\nDoesn't this merely show a bad discipline? What were you envisioning to\ndo to your detached HEAD state if the rebase were to succeed? IOW, if the\nstate was so precious, why did you decide to switch to topic and rebase it\nonto that state, without marking?\n\n> Are there valid cases where the current behavior is bettter?\n\nI don't particularly like the \"when aborted it returns to the original\nlocation\" behaviour even for a single argument \"git rebase A\" case (I do\ndeeply care about the tip of the branch that you attempted to rebase _is_\nset back to the original state, but I don't care deeply on which branch\nyou would end up on myself), but because \"git rebase A B\" is a shorthand\nfor \"git checkout B; git rebase A\" (at least that is how I view it\nmyself), I would imagine that it would be more surprising to switch back\nto the branch you were on which may not have anything to do with A nor B.\n\nAt least going back to B conceptually makes more sense in one use case I\nhave, which was the original reason I invented rebase with the \"checkout B\nand rebase it ono A\" shorthand in the first place (see 59e6b23), back when\nI was an active contributor throwing patches at Linus (note that back then\nI didn't have \"abort then go back\" in the code--and that is why I don't\ncare too deeply about this \"which branch should I be after aborting?\"\nmyself).\n\nThe reason I tried to rebase B on A with the short-hand form was because I\nwanted to clean up what is on B; I may say \"abort\" when my first attempt\nto rebase failed because it was a bit too much to bite at once (e.g. the\nhistory diverged a bit too much since B forked from A's ancestor).\n\nBut then, the next thing I would want to do in such a case after aborting\nis not to give up and forget about what I needed to do, which is to clean\nup B into a shape easier to merge with the updated codebase that leads to\nA.  I would want to stay on B and examine the situation a bit deeper, and\ntry to figuire out a different base (e.g. a bit older commit in the\nhistory leading to A) to rebase to, so that I can keep up with the other\nbranch incrementally without lagging too far behind.  Switching away from\nthe original B would be majorly annoying in such a case.\n"},{"id":"163283","messageId":"7v8vwjihsu.fsf@alter.siamese.dyndns.org","threadId":"26722","inReplyTo":"7vmxkzijpt.fsf@alter.siamese.dyndns.org","subject":"Re: [RFD] make rebase abort to original branch, not rebased branch","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-03-13T07:46:41Z","receivedAt":"2011-03-13T07:46:41Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n>> Are there valid cases where the current behavior is bettter?\n> ...\n> I don't particularly like the \"when aborted it returns to the original\n> location\" behaviour even for a single argument \"git rebase A\" case (I do\n> deeply care about the tip of the branch that you attempted to rebase _is_\n> set back to the original state, but I don't care deeply on which branch\n> you would end up on myself), but because \"git rebase A B\" is a shorthand\n> for \"git checkout B; git rebase A\" (at least that is how I view it\n> myself), I would imagine that it would be more surprising to switch back\n> to the branch you were on which may not have anything to do with A nor B.\n>\n> At least going back to B conceptually makes more sense in one use case I\n> have, which was the original reason I invented rebase with the \"checkout B\n> and rebase it ono A\" shorthand in the first place (see 59e6b23), back when\n> I was an active contributor throwing patches at Linus (note that back then\n> I didn't have \"abort then go back\" in the code--and that is why I don't\n> care too deeply about this \"which branch should I be after aborting?\"\n> myself).\n> ...\n\nHaving said all that, my opinion would be very different if the definition\nof \"git rebase A B\" were different.  I can imagine that some people may be\ntempted to (mis)understand the form of the command as a way to \"rebase B\non top of A, even though I am doing something unrelated to B (my work may\nor may not be related to A), because I need to help somebody who wants to\nhave an access to an updated B _now_, and I'll continue what I am doing\n(which is not related to B) after I am done rebasing\".\n\nActually, I would not say that such a workflow is unreasonable.\n\nAnd for people who want such a workflow out of \"rebase A B\", it would be a\nbug that the command does not to come back to your original branch when it\nfinishes rebasing B on top of A, and it would equally be a bug when it\nstops with a conflict and you tell it to abort. In _both_ cases, you would\nwant to come back to the branch you started from.\n\nBut \"git rebase A B\" after successful completion does not come back to\nyour original branch (it stays on B), because the current semantics of the\ncommand is not about supporting such a workflow.\n"},{"id":"163287","messageId":"alpine.DEB.2.00.1103131013370.15442@debian","threadId":"26722","inReplyTo":"7vmxkzijpt.fsf@alter.siamese.dyndns.org","subject":"Re: [RFD] make rebase abort to original branch, not rebased branch","fromName":"Martin von Zweigbergk","fromEmail":"martin.von.zweigbergk@gmail.com","sentAt":"2011-03-13T14:58:08Z","receivedAt":"2011-03-13T14:58:08Z","isPatch":false,"sender":{"key":"martinvonz@gmail.com","avatar":"https://avatars.githubusercontent.com/u/891642?v=4"},"body":"On Sat, 12 Mar 2011, Junio C Hamano wrote:\n\n> Martin von Zweigbergk <martin.von.zweigbergk@gmail.com> writes:\n> \n> > In most cases, this is just a small annoyance, since it's usually\n> > quick and easy to manually switch back to the original\n> > branch. However, I have run into at least two cases where it has been\n> > a bit more annoying:\n> >\n> >  1. When on a detached HEAD and running \"git rebase HEAD topic\", if\n> >     you abort the rebase, you will have to look up the old commit in\n> >     the reflog.\n> \n> Doesn't this merely show a bad discipline? What were you envisioning to\n> do to your detached HEAD state if the rebase were to succeed? IOW, if the\n> state was so precious, why did you decide to switch to topic and rebase it\n> onto that state, without marking?\n\nThis usually happens when I see something that looks a bit suspicious\nin one of my own commits on my topic branch. I then check out that\ncommit to have a look and perhaps run some test. If I find something\nbroken, I would fix it and either amend the commit or create a new\ncommit on top. I would then run \"git rebase --onto HEAD HEAD~1 topic\"\nor \"git rebase HEAD topic\", respectively. If the merge conflicts turn\nout to be bigger than I expected, I may decide to abort and to instead\ncreate a new branch for the commit(s) until I find time/energy.\n\n> > Are there valid cases where the current behavior is bettter?\n> \n> I don't particularly like the \"when aborted it returns to the original\n> location\" behaviour even for a single argument \"git rebase A\" case\n\nThis has sometimes annoyed me as well. Maybe a --stop/discard would be\na nice alternative to \"rf -r .git/(rebase-apply|rebase-merge)\"?\n\n> At least going back to B conceptually makes more sense in one use case I\n> have, which was the original reason I invented rebase with the \"checkout B\n> and rebase it ono A\" shorthand in the first place (see 59e6b23), back when\n> I was an active contributor throwing patches at Linus (note that back then\n> I didn't have \"abort then go back\" in the code--and that is why I don't\n> care too deeply about this \"which branch should I be after aborting?\"\n> myself).\n> \n> The reason I tried to rebase B on A with the short-hand form was because I\n> wanted to clean up what is on B; I may say \"abort\" when my first attempt\n> to rebase failed because it was a bit too much to bite at once (e.g. the\n> history diverged a bit too much since B forked from A's ancestor).\n> \n> But then, the next thing I would want to do in such a case after aborting\n> is not to give up and forget about what I needed to do, which is to clean\n> up B into a shape easier to merge with the updated codebase that leads to\n> A.  I would want to stay on B and examine the situation a bit deeper, and\n> try to figuire out a different base (e.g. a bit older commit in the\n> history leading to A) to rebase to, so that I can keep up with the other\n> branch incrementally without lagging too far behind.  Switching away from\n> the original B would be majorly annoying in such a case.\n\nCertainly a valid use case. Maybe the best solution would be to\nintroduce a new kind of --abort (say --abort-to-branch-before-rebase,\nbut with a better name)?\n\n\n/Martin\n"},{"id":"163288","messageId":"4D7CE26F.9070608@miseler.de","threadId":"26722","inReplyTo":"alpine.DEB.2.00.1103131013370.15442@debian","subject":"Re: [RFD] make rebase abort to original branch, not rebased branch","fromName":"Alexander Miseler","fromEmail":"alexander@miseler.de","sentAt":"2011-03-13T15:27:43Z","receivedAt":"2011-03-13T15:27:43Z","isPatch":false,"sender":{"key":"alexander@miseler.de","avatar":null},"body":">>> In most cases, this is just a small annoyance, since it's usually\n>>> quick and easy to manually switch back to the original\n>>> branch. However, I have run into at least two cases where it has been\n>>> a bit more annoying:\n>>>\n>>>  1. When on a detached HEAD and running \"git rebase HEAD topic\", if\n>>>     you abort the rebase, you will have to look up the old commit in\n>>>     the reflog.\n>>\n>> Doesn't this merely show a bad discipline? What were you envisioning to\n>> do to your detached HEAD state if the rebase were to succeed? IOW, if the\n>> state was so precious, why did you decide to switch to topic and rebase it\n>> onto that state, without marking?\n> \n> This usually happens when I see something that looks a bit suspicious\n> in one of my own commits on my topic branch. I then check out that\n> commit to have a look and perhaps run some test. If I find something\n> broken, I would fix it and either amend the commit or create a new\n> commit on top. I would then run \"git rebase --onto HEAD HEAD~1 topic\"\n> or \"git rebase HEAD topic\", respectively. If the merge conflicts turn\n> out to be bigger than I expected, I may decide to abort and to instead\n> create a new branch for the commit(s) until I find time/energy.\n\nThis can be easily fixed for your own repository by installing a pre-rebase hook that force-sets a temporary branch (named e.g. \"pre-rebase\") to the current commit before starting the rebase. I can highly recommend having such a hook, it's damn useful.\n"}]}