Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

quoted text
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html