Re: [PATCH v2 04/13] Teach rebase interactive the mark command
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Apr 29, 2008, 23:06 UTC
- Message-ID
- <7v63u05khw.fsf@gitster.siamese.dyndns.org>
- In-Reply-To
- <alpine.DEB.1.00.0804292355060.17469@eeepc-johanness>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
Show 17 quoted lines
> On Tue, 29 Apr 2008, Junio C Hamano wrote: > >> Johannes Schindelin <Johannes.Schindelin@gmx.de> 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. > > I do not understand. The topological order assures that you have > rewritten every commit that needs to be rewritten before rewriting the > current commit.
Perhaps it would help to go back to the message J6t incompletely quoted, and try the example with the parent order of Y swapped (i.e. B == Y^2, C == Y^1)
Recreating X and Y both need to refer to the rewritten B as the parameter to "merge" insn. You create X first then you cannot refer to B anymore to recreate Y. The other way around you cannot name B to recreate X.