From: Bert Wesarg <bert.wesarg@googlemail.com>
Date: Sat, 11 Apr 2009 15:40:04 GMT
Subject: Re: [PATCH] Add "list" and "rm" sub commands to tg-depend
Message-ID: <36ca99e90904110840g35fa3b37m45f0286cb1f99db6@mail.gmail.com>
In-Reply-To: <20090409201515.GA4218@pengutronix.de>

2009/4/9 Uwe Kleine-König <u.kleine-koenig@pengutronix.de>:
> Hello,
>
> On Thu, Apr 09, 2009 at 08:01:04PM +0200, Bert Wesarg wrote:
>> 2009/4/9 Ira Weiny <weiny2@llnl.gov>:
>> > On Thu, 9 Apr 2009 14:43:37 +0200
>> > Uwe Kleine-König <u.kleine-koenig@pengutronix.de> wrote:
>> >> You might want to check
>> >>
>> >>       http:// thread.gmane.org/gmane.comp.version-control.git/114581
>> >
>> > Ah this brings up more issues I had not thought about...  :-(  But perhaps
>> > Bert's work could be used to help implement "rm".  Thoughts?
>> No, it wont help. Because the base and tip of the topic should not
>> changed in respect to the old state (expect for .topdeps of course).
>>
>> If you really want to remove a dependency, you need to revert a merge
>> of this dep from the topic base. which is not possible today, or maybe
>> I have just an idea for this:
>>
>>   'topic': the topic
>>   'base':  the base of the topic, i.e. a merge from all dependent
>> topics dep0, ..., depN
>>
>> say you want to remove dep0
>>
>>   1) merge all deps dep1, ..,depN into 'new-base'
>>
>>   2) merge 'new-base' into base with the merge driver 'theirs', that
>> would overwrite all changes from dep0 in the 'base'
>>
>>   3) update 'topic' to the updated 'base'
>>
>> Any thoughts from someone who knows more than me?
> Some time ago I thought about a similar issue:
>
> I based a branch on top of the Linux tree of the ARM maintainer (in the
> following called "rmk") and decided later to base it on top of Linus'
> tree.  So I did ~:
>
>        git checkout refs/top-bases/$branch
>        git merge -s theirs linus/master
>        git checkout $branch
>        sed -i s,rmk,linus, .topdeps
>        git add -f .topdeps
>        git commit -m $commitmsg
>        tg update
>
> When I thought about it with pencil and paper back then, I saw a problem
> with that approach.  Now I invested some time now to verify it really
> exists:  In fact I reverted the changes in the rmk/master branch.
> Consider Linus pulls from rmk and I update my topgit branch.  Guess what
> happens?  Linus' pull + my revert yield Linus' tree without rmk's
> changes.
>
> Here is my recipe:
>
>        # prepare linus/master
>        git init
>        echo 'VERSION=2.6.28' > Makefile
>        git add Makefile; git commit -m 'v2.6.28'
>        git branch -m master linus/master
>
>        # prepare rmk/master
>        git checkout -b rmk/master
>        echo 'support for some machine' > arm.c
>        git add arm.c; git commit -m 'support for some machine'
>
>        # new topgit branch
>        tg create t/test
>        echo change > lib.c
>        git add lib.c; git commit -m 'tralala'
>
>        # Linus goes on ...
>        git checkout linus/master
>        echo 'VERSION=2.6.29-rc1' > Makefile
>        git add Makefile; git commit -m 'v2.6.29-rc1'
>
>        # "rebase" test branch on linus/master
>        git checkout refs/top-bases/t/test
>        git symbolic-ref HEAD refs/top-bases/t/test
>        git merge --no-commit linus/master
>        git read-tree linus/master
>        git commit
>        rm arm.c
>        git checkout t/test
>        sed -i s/rmk/linus/ .topdeps
>        git add .topdeps; git commit -m 'change dep: rmk/master -> linus/master'
>        tg update
>
>        # Linus pulls from rmk
>        git checkout linus/master
>        git merge rmk/master
>
>        # update test to linus+rmk
>        git checkout t/test
>        tg update
>
>        # inspect:
>        git diff linus/master refs/top-bases/t/test
>
> The last command shows that refs/top-bases/t/test doesn't have arm.c
> :-/
>
> I'm sure the dependency deletion has exactly the same problem.
You're probably right. I just found the old discussion about
dependencies removal [1]:

On zo, 2008-09-21 at 16:24 +0200, Petr Baudis wrote:
> The problem is that you can undo the merge content, but not the history
> information. So this revert can e.g. propagate even into branches which
> still *should* depend on the other branch, you get into trouble when you
> want to make your branch depend on the other one anyway, etc.

On di, 2008-09-23 at 15:27 +0200, Petr Baudis wrote:
> what we can't make to work is just the
> most generic case, but e.g. if master is a *leaf* branch nothing else
> depends on and it can't get the branch through multiple paths, you can
> do the dependency removal rather easily (if it can get through multiple
> paths, you can still do it but you might have to deal with big
> conflicts).

Maybe the leaf solution could be done.  Only directly depending
branches from the transitive reduction should be removable.  This
would help for the 'tip'/'current' branch usecase, for collecting
topics.

Bert

[1] http://thread.gmane.org/gmane.comp.version-control.git/95458/focus=96093
>
> Best regards
> Uwe