Implement facility to undo, then re-write a previous commit, as multiple commits
I'd like to be able to split existing changesets, similar to what is possible with 'git rebase'.
Mostly this is useful for preparation for cherry-picking some functionality that is needed on more than one branch.
I'm not suggesting that you necessarily inflict something as complexed as 'git rebase' in plastic.
Instead it might take the form of:
A. Do a subtractive merge of the commit I want to split. Allow me to then re-merge the subtractively merged commit, without generating any merge links, over the current changeset (or maybe invent some kind of new merge link that visually indicates this in the GUI).
Items from this commit would then just become uncommitted items in the workspace, which I can then bundle into as many new commits, as I see fit, using the existing functionality, which I can then cherry-pick, as required.
OR
B. Allow genuine editing of history, with all the potential trouble for downstream branches that it brings. Presumably, it would involve splicing history, and adjusting parent/child pointers in the DAG.
kdm
shared this idea
-
rdealba
commented
Hello,
The scenario you explained is very interesting, understable and possible in specific scenarios. So, if you don't mind to break the immutable history, it would be a nice functionality for certain cases.
However, we would have to set some restrictions where the commit couldn't be splitted. For example, an already cherry-picked changeset should never be splitted to avoid trazability issues.
-
psantosl
commented
Hi,
What you propose is certainly interesting. The only downside is that so far we never allowed to modify history since we consider 'immutable' history to be a good thing. I mean, as a whole concept I sort of prefer immutable history than being able to edit it.
That being said, there are certainly cases where splitting a checkin makes sense... I'll ask Borja and Rubén, the two main coders behind the entire merge system, to join to this discussion.