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?
Bert
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.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
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).
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:
quoted
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:
quoted
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).
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/ |