Re: [PATCH v2 04/13] Teach rebase interactive the mark command

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

Hi,

On Tue, 29 Apr 2008, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > 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.

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