Martin von Zweigbergk [off-list ref] 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?
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 (I do
deeply care about the tip of the branch that you attempted to rebase _is_
set back to the original state, but I don't care deeply on which branch
you would end up on myself), but because "git rebase A B" is a shorthand
for "git checkout B; git rebase A" (at least that is how I view it
myself), I would imagine that it would be more surprising to switch back
to the branch you were on which may not have anything to do with A nor B.
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.
On Sat, 12 Mar 2011, Junio C Hamano wrote:
Martin von Zweigbergk [off-list ref] writes:
quoted
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.
quoted
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
quoted
quoted
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.
This 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.