Re: [PATCH] Add "list" and "rm" sub commands to tg-depend

2009/4/9 Uwe Kleine-König [off-list ref]:

Hello,

On Thu, Apr 09, 2009 at 08:01:04PM +0200, Bert Wesarg wrote:

quoted

2009/4/9 Ira Weiny [off-list ref]:

quoted

On Thu, 9 Apr 2009 14:43:37 +0200
Uwe Kleine-König [off-list ref] wrote:

quoted

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