Junio C Hamano schrieb: > In the context of "rebase -i", this may not be a problem, but by forcing > us to name commits always with original commits, we cannot build (instead > of rebuild) a history that does not yet exist using the sequencer > machinery, can we? > > If we want to transplant "^C ^N O" in this history elsewhere: > > --o---C---N > / > B---M > / / > O---A > > while inserting a new fix-up commit F on top of B before we merge that > side branch to rewritten A: > > --o---C---N' > / > B'--X---M' > / / > O---Q-------A' > > Would/Should the machinery somehow figure out that the merge between the > rewritten A (which is A') and an inserted commit X (which is made on top > of the rewritten B) corresponds to M in the original history? No. The 'merge' insn tells the original merge commit. So, rebase would suggest this todo list: pick B reset Q pick A merge M A B merge N M C and you would have to change it to pick B pick X <-- reset Q pick A merge M A X <-- merge N M C But you could just as well do this: edit B <-- reset Q pick A merge M A B merge N M C When the 'edit B' stops, HEAD is at B'. Now you git-am X, then 'rebase --continue'. Since now HEAD is at X, X is recorded as the rewritten version of B, and the 'merge M A B' would pick X as the second parent. -- Hannes -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
