On Sat, Sep 03, 2005 at 12:32:03PM -0700, Junio C Hamano wrote:
> Sam Ravnborg <[EMAIL PROTECTED]> writes:
>
> > As explained in another mail what we want to do is actually to
> > transpose the changes made to F to the now renamed file G.
> > So we end up with G containing the modifications made to F.
> >
> > Also we want to include the new file K.
>
> Thanks for the clarification. But the principles are the same.
Not the way I read your explanation.
Lets try to cook up an example:
Common ancestor looks like this:
foo/foo.c
Then we have two lines of parallel development
dev-line-0 modifes foo/foo.c
dev-line-1 moves foo/foo.c to bar/bar.c
In addition dev-line-1 adds a second file bar/Makefile
So what should happen when we merge the two dev-lines?
The resulting tree should look like this:
bar/bar.c (including the modifications down in dev-line-1 to foo.c
bar/Makefile as added in dev-line-2
If this fits into your longer description - then yes this is the same
principle. But I failed to see it fit, therefore this simple example.
If the problem is not fully understood it can be difficult to come up
with the proper solution. And with the example above the problem should
be really easy to understand.
Then we have the tree as used by hpa with a few more mergers in it. But
the above is what was initial tried to do with the added complexity of a
few more renames etc.
Sam
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
