Hello Bert, On Sat, Apr 11, 2009 at 05:40:04PM +0200, Bert Wesarg wrote: > 2009/4/9 Uwe Kleine-König <u.kleine-koenig@xxxxxxxxxxxxxx>: > > Hello, > > > > On Thu, Apr 09, 2009 at 08:01:04PM +0200, Bert Wesarg wrote: > >> 2009/4/9 Ira Weiny <weiny2@xxxxxxxx>: > >> > On Thu, 9 Apr 2009 14:43:37 +0200 > >> > Uwe Kleine-König <u.kleine-koenig@xxxxxxxxxxxxxx> 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. I think I've a solution. Not an implementation yet, but the right thoughs (I hope): tg should not merge using the full history but fake the collapsed (as in tg export --collapse) history as HEAD. > 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 This link isn't optimal. The highlighted message doesn't contain the citations above :-/. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | -- 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