On Tue, Feb 13, 2018 at 12:22 PM, Psidium Guajava <psiid...@gmail.com> wrote: > Hello git community, > > I'd like to add a new feature in git-rebase: --undo-skip. > But first, I'd like to consult with the experts if it would be > beneficial for the project and if my line of tought is correct. > > Imagine that you are working on a feature for a long time, but there > are multiple bug fixes happening at `master` branch at the same time. > After lots of commits on both ends, you decide to rebase your changes > on top of the current `master` branch. > After lots of conflict resolution steps, you mistakenly call > `git-rebase --skip` instead of `git-rebase --continue`, thus losing a > commit of your work, and possibly inserting bugs in your project. > The only solution for this right now would be to abort the current > rebase and start over. > > It seems that a feature like this have been requested once on the mail list > [1]. > > I propose the existence of --undo-skip on git-rebase's `$action` domain. > > How I fixed it when that happened with me was (just after running the > wrong skip): > > 1. I figured I was making a rebase that used `git-am` as a backend. > 2. In the rebase-apply directory I searched for the patch file with > the change I just skipped. > 3. Found the `rebase-apply/next` file. > 4. Wrote the number of the patch I skipped - 1 in rebase-apply/next. > 5. run `git rebase --skip` again on the repository. > > This made the lost patch appear again and I could `--continue` it this time.
I think this could also be done with "git rebase --edit-todo", which brings up the right file in your editor. > I propose the addition of an action `--undo-skip`, that could be > called only after a wrongfully called `--skip`. > `git rebase --undo-skip`. > I would implemented it to do programatically what I did by hand when > that happened with me. > > Here are my questions for you: > 1. Would this be beneficial for the users? I guess it is. > 2. For `rebase--am`, I would need to change `git-rebase--am.sh` file, correct? > 3. Can I assume `builtin/am.c` will always store its information on > `$state_dir/next` and `$state_dir/$patchnumbers`? > 4. How hard would it be to add that logic for `rebase--interactive` > and `rebase--merge` backends? cc'd Johannes who is currently working on revamping rebase. > > Also, a little unrelated with this issue: > 5. What happened to the rewrite of rebase in C [2]? I couldn't find > any information after 2016. > > [1] https://public-inbox.org/git/201311011522.44631.tho...@koch.ro/ > [2] > https://public-inbox.org/git/1457779597-6918-1-git-send-email-pyoka...@gmail.com/ cc'd Paul Tan, maybe he recalls the situation.
