Feature request: Support multiple cuts
rwe opened this issue · comments
Frequently when splitting a commit, I want to split it into more than two pieces. For example, there may be several kinds of independent kinds of changes that need to be split out; or a commit with several instances of the same kind of change, that might need to split per each file or module.
git-revise is very useful for quickly cutting up those commits, and faster than rebasing, but it currently only supports "part [1]"/"part [2]". In order to make multiple cuts, currently it requires repeated invocations, manually copying the commit hashes (since the target hash for a new cut will always be different each time).
It would be extremely useful to support repeated cuts. This also may not be very difficult to do: for example just restart cutting on the "part [2]" until the user specifies an empty cut.
manually copying the commit hashes (since the target hash for a new cut will always be different each time).
This is a point for using a Git client like Magit or Tig that allows to visually select a commit.
Alternatively, you can use something like git revise --cut :/my-fix to cut the most recent commit that use my-fix in its message, see gitrevisions(7). With either of those, launching another git-revise cut command is a matter of a couple of keystrokes.
When I saw this, I thought of a different interface: for each hunk, instead of only deciding between two destination commits with y/n, the user could have the option to put it into a new commit.
Restarting the cutting on part 2 seems reasonable because one can just use q or a to leave one cut part empty.
However, up to now, an empty cut part has been an error. With this change it would probably only be an error on the first cut, which seems overly complex.
What should happen when the users presses Ctrl-C after the first successful cut? I guess no cut should be made.
This is a point for using a Git client like Magit or Tig that allows to visually select a commit.
Yes, or tmux-thumbs etc. It's just an annoying extra step.
Alternatively, you can use something like
git revise --cut :/my-fixto cut the most recent commit that usemy-fix
That's sometimes doable, but when revising several commits it's not always easy to remember the precise commit message phrasing, especially if there are multiple similar commits like "Add X to A", "Use X in B", and that is especially the case while performing multiple cuts of similar changes in preparation for later movement.
When I saw this, I thought of a different interface:
That's what I originally envisioned, too, and I think it would be a better interface. However, I realized it may become difficult to handle things like multiple cuts of the same original hunk. I'm also not sure how much of the built-in patch selection mechanism git-revise uses and whether it would even be feasible to customize that interface in between hunks. The suggestion for re-cutting part 2 seemed like a reasonable shortcut.
However, up to now, an empty cut part has been an error
That's true, and also giving the user a way to abort is important. So perhaps instead of just assuming an empty cut is a successful end, prompt for "continue or quit"?