Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > It is a simple matter of the word "acyclic" in the term "DAG". It means > that whenever you need to refer to a commit, it either comes before or > after the commit you need it for, not both directions. I fell in the same "acyclic" fallacy before I realized it was a mistake, especially after thought about the "rewritten B needs to be used more than twice as a merge source" issue. That's why I earlier said the beauty of your approach is attractive but it "unfortunately" breaks down. For "rebase -i", the tool needs to spit out insns (and again I'd prefer not to require the tools to be clever to be able to write them out), and the generated sequence needs to be easily understood by the end user who needs to be able to edit (e.g. drop lines, reorder them, s/pick/edit/) and easily visualize what the resulting shape of the history would be. If we limit ourselves to the context of a non-merge-preserving "rebase -i", the insns will not need 'mark' (nor 'merge') and the resulting todo file would look identical in both approaches. But we also would want to have a sequencer generic enough to be capable of faithfully reproducing a history with merges. -- 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
