Ccing the mailing list.
On Thu, Dec 20, 2018 at 07:26:53PM +0100, Kevin Daudt wrote:
It would be anoying for users to have to constantly confirm when they
run git rebase --continue. Rather than asking confirmation, it would be
better to make it easy to go back to the previous state.
I meant confirmation for --committer-date-is-author-date
option.
As Thomas said, it should be possible to undo the action
using reflog, although this seems not as easy as it should
be yet.
pasquali
Am 20.12.2018 um 22:11 schrieb Ricardo Biehl Pasquali:
Ccing the mailing list.
On Thu, Dec 20, 2018 at 07:26:53PM +0100, Kevin Daudt wrote:
quoted
It would be anoying for users to have to constantly confirm when they
run git rebase --continue. Rather than asking confirmation, it would be
better to make it easy to go back to the previous state.
I meant confirmation for --committer-date-is-author-date
option.
As Thomas said, it should be possible to undo the action
using reflog, although this seems not as easy as it should
be yet.
The git rebase documentation has
ORIG_HEAD is set to point at the tip of the branch before the reset.
so doing
git reset ORIG_HEAD
does reset to the state before the rebase.
For avoiding the original problem of --co completing to
--committer-date-is-author-date I'm using the alias rc for git rebase
--continue.
On Thu, Dec 20, 2018 at 10:37:00PM +0100, Thomas Braun wrote:
The git rebase documentation has
ORIG_HEAD is set to point at the tip of the branch before the reset.
so doing
git reset ORIG_HEAD
does reset to the state before the rebase.
That's pretty easy :-)
For avoiding the original problem of --co completing to
--committer-date-is-author-date I'm using the alias rc for git rebase
--continue.
It's definetly an alternative. Anyway, ORIG_HEAD reset is
sufficient for the cases when enter is hit before noticing
the completion string.
Thank you!
pasquali