Allow dropping / removing commits in interactive mode

[alcroito]

No description provided.

[Manishearth]

A key invariant this tool operates on is that your actual file state doesn't change.

Now, this could work by warning you that your file state will change, and then applying those changes to the working directory.

You can do this now by moving the commit to the end and replacing "pick" with "index".

[mystor]

As @Manishearth mentioned, this tool currently tries to avoid changes which would cause your checkout to be modified, such as removing commits. It'll require some design work to figure out if and how a feature like this fits into the git revise model.

[alcroito]

It would just feel natural that the regular features that are supported by git rebase --interactive would also be supported by git revise --interactive, otherwise i would have to sometime follow up a revise with a rebase, and that will touch the checkout, and thus could cause rebuilds.

[Manishearth]

This tool is designed for a specific kind of history editing, though, it's not a drop in rebase replacement

[alerque]

@alcroito The only case I can think of that would fit this tool would be dropping empty commits, which are pretty rare in practice. I for one would expect to have to do a rebase not a revise if something I was doing along the way was going to leave me with a different final state than what I'm in now. In other words rebase if the code is going to change along the way or revise if you are just reorganizing how the history reflects how you got to the exact state you are in now.

[mystor]

@alcroito The only case I can think of that would fit this tool would be dropping empty commits, which are pretty rare in practice. I for one would expect to have to do a rebase not a revise if something I was doing along the way was going to leave me with a different final state than what I'm in now. In other words rebase if the code is going to change along the way or revise if you are just reorganizing how the history reflects how you got to the exact state you are in now.

The empty commit dropping also works OK. If you need to do that you can fixup the commit into the previous one, and nothing will change :-).

[alerque]

Savvy.

[rwe]

I feel like it would be pretty straightforward and ergonomic to internally treat drop as the currently-manual "move to end and s/pick/index/". That would behave exactly as rebase for those cases, modulo git-revise's constraint that the working tree is left untouched.

Given that, it doesn't seem that index needs to exist at all: index is required to go at the end anyway, so in all cases it's the same as that style of drop but with an additional tedium of having to manually move it to the end.

[peterjc]

I found this issue while looking into a faster interactive git rebase for a special use case.

I have a git history with a few 1000 commits exported from a wiki. Some of these commits are spam, generally followed by spam removal commit later (not necessarily the next commit which could be to a different file).

I'm trying to rebase to drop the spam commits, which in turn mean the spam-reverts become empty commits, and I'll probably want to drop those too.

[There are of course more complicated examples where the cleanup wasn't a simple single commit, and a conflict resolution would be needed, but my goal is no change to the final state of the files on disk]

It sounds like the above proposal would handle at least some of these history edits.