On Sat, 12 Mar 2011, Junio C Hamano wrote: > Martin von Zweigbergk <martin.von.zweigbergk@xxxxxxxxx> writes: > > > In most cases, this is just a small annoyance, since it's usually > > quick and easy to manually switch back to the original > > branch. However, I have run into at least two cases where it has been > > a bit more annoying: > > > > 1. When on a detached HEAD and running "git rebase HEAD topic", if > > you abort the rebase, you will have to look up the old commit in > > the reflog. > > Doesn't this merely show a bad discipline? What were you envisioning to > do to your detached HEAD state if the rebase were to succeed? IOW, if the > state was so precious, why did you decide to switch to topic and rebase it > onto that state, without marking? This usually happens when I see something that looks a bit suspicious in one of my own commits on my topic branch. I then check out that commit to have a look and perhaps run some test. If I find something broken, I would fix it and either amend the commit or create a new commit on top. I would then run "git rebase --onto HEAD HEAD~1 topic" or "git rebase HEAD topic", respectively. If the merge conflicts turn out to be bigger than I expected, I may decide to abort and to instead create a new branch for the commit(s) until I find time/energy. > > Are there valid cases where the current behavior is bettter? > > I don't particularly like the "when aborted it returns to the original > location" behaviour even for a single argument "git rebase A" case This has sometimes annoyed me as well. Maybe a --stop/discard would be a nice alternative to "rf -r .git/(rebase-apply|rebase-merge)"? > At least going back to B conceptually makes more sense in one use case I > have, which was the original reason I invented rebase with the "checkout B > and rebase it ono A" shorthand in the first place (see 59e6b23), back when > I was an active contributor throwing patches at Linus (note that back then > I didn't have "abort then go back" in the code--and that is why I don't > care too deeply about this "which branch should I be after aborting?" > myself). > > The reason I tried to rebase B on A with the short-hand form was because I > wanted to clean up what is on B; I may say "abort" when my first attempt > to rebase failed because it was a bit too much to bite at once (e.g. the > history diverged a bit too much since B forked from A's ancestor). > > But then, the next thing I would want to do in such a case after aborting > is not to give up and forget about what I needed to do, which is to clean > up B into a shape easier to merge with the updated codebase that leads to > A. I would want to stay on B and examine the situation a bit deeper, and > try to figuire out a different base (e.g. a bit older commit in the > history leading to A) to rebase to, so that I can keep up with the other > branch incrementally without lagging too far behind. Switching away from > the original B would be majorly annoying in such a case. Certainly a valid use case. Maybe the best solution would be to introduce a new kind of --abort (say --abort-to-branch-before-rebase, but with a better name)? /Martin -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html