Johannes Schindelin <johannes.schindelin@xxxxxx> writes: > Think of --recreate-merges as "--preserve-merges done right". It > introduces new verbs for the todo list, `label`, `reset` and `merge`. > For a commit topology like this: > > A - B - C > \ / > D > > the generated todo list would look like this: > > # branch D > pick 0123 A > label branch-point > pick 1234 D > label D > > reset branch-point > pick 2345 B > merge 3456 D C Yup. I've seen this design talked about on list in the past, and I've always felt that this is "sequencer done right". At the first glance, it may feel somewhat unsatisfying that "merge" has to say effects of which commits should be reflected in the result and which commot to take the log message from, i.e. (recreated)D is merged to form the resulting tree, and 3456=C is used for the log, to recreate C in the above example, while "pick" always uses the same commit for both, i.e. recreated B inherits both the changes and log message from the original B=2345 (or depending on the readers' point of view, "merge" is allowed to use two different commits, while "pick" is always limited to the same one). But I think this distinction is probably fundamental and I am not opposed to it at all. The result of "pick" has only one parent, and the parent is determined only by the previous actions and not by anything on the "pick" line in the todo list. But the result of "merge" has to record all the other parents, and only the first parent is determined implicitly by the previous actions. We need to tell the "merge" command about "3456=C" in order to recreate the effect of original merge commit (i.e. changes between B and C) as well as its log message, and we also need to tell it about label "D" that it is the "other parent" that need to be recorded. Obviously "merge" command syntax should allow recreating an octopus, so whenever I said "two" in the above, I meant "N". The original merge commit is needed so that the effect to replay (roughly: a patch going to the original merge result from its first parent) can be learned from the existing history, and all the other "N-1" parents needs to be given (and they must have been already created in the todo list) so that the resulting recreated merge can be recorded with them as parents (in addition to the first parent that is implicitly given as the result of all the previous steps). One interesting (and probably useful) thing to notice is that if A were not rebased in the above sample picture, and only B were the one that was tweaked, then a recreated C may use the same original D as its side parent, and the mechanism outlined above naturally can support it by allowing an un-rewritten commit to be given as a side parent when "merge" is redoing C. I probably won't have time to actually look at the code for a few days, but I am reasonably excited about the topic ;-) Thanks.
