Hi, On Tue, 29 Apr 2008, Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > > > On Tue, 29 Apr 2008, Junio C Hamano wrote: > > > >> 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. > > > > 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. If you refer to "B" as the "short name of the original commit which refers to the rewritten commit as soon as B was rewritten", then I really do not see the problem. Every commit has 0..n parents. These are properly identified before rebasing. Some of them have to be rewritten, because they are rebased. So if you order the commits topologically, so that ancestors come first, you will have to jump around a bit with the "reset" command, but you can basically make sure that all parents that needed rewriting were rewritten already before rewriting that commit. Now, if you want to split a commit, you may want to refer to the original commit instead of an already rewritten commit, but I think that this occasion is rare enough, that we can ask the user to tag that commit, and refer to that commit by its tag in the todo list. Or you write down the original's long name and use that one. But if you use the _default_ todo list, i.e. you want to rebase preserving merges without interfering manually with the process, what I said about the topological ordering still holds true. At no point will you need to refer _both_ to the original _and_ to the rewritten commit name. Come to think of it, I cannot think of a (default) case where the _original_ name of a to-be-rewritten commit has to be referred to, except for the "pick" command. Ciao, Dscho -- 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
