Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: >> though). The "one sequencer to rule them all" may even have to say >> "now give name ':1' to the result of the previous operation" in one >> step and in another later step have an instruction "merge ':1'". >> When that happens, you cannot even pre-populate the commit object >> when the sequencer reads the file, as the commit has not yet been >> created at that point. > > These considerations are pretty hypothetical. I would even place a bet > that we will *never* have ":1" as names, not if I have anything to say... > ;-) If you can always work with pre-existing commit, then you can validate all object references that appear in the instructions upfront. I was sort of expecting that, when you do the preserve-merges mode of "rebase -i", you would need to jump around, doing "we have reconstructed the side branch on a new 'onto', let's give the result this temporary name ':1', and then switch to the trunk (which would call for 'reset <commit>' instruction) and merge that thing (which would be 'merge :1' or perhaps called 'pick :1')", and at that point you no longer validate the object references upfront. If you do not have to have such a "mark this point" and a "refer to that point we previously marked", then I agree that you should be able to pre-validate and keep the result in the structure.