It would be good to be able to remove a tg branch properly, for instance when upstream included a patch and the topic branch is thus obsolete. The following discussion has already happened on the Git list, only one message is relevant and quotes my original mail: X-Url: http://thread.gmane.org/gmane.comp.version-control.git/95858 Date: Sun, 14 Sep 2008 23:03:16 +0200 From: Petr Baudis <pasky@suse.cz> To: martin f krafft <madduck@madduck.net> Cc: git@vger.kernel.org Subject: Re: TopGit: how to deal with upstream inclusion In-Reply-To: <20080914203043.GA4872@lapse.rw.madduck.net> Message-ID: <20080914210316.GJ10360@machine.or.cz> Hi, upstream should never pull TopGit branches! They have ugly history and contain .topdeps and .topmsg junk files. That's what tg patch and tg export is there for. :-) If upstream applies the changes, the branch becomes unnecessary and then it is ok to have some command like 'tg depend rm' to get rid of the branch, since the *changes* aren't going away, thus we don't need to create any "revert commits", which is the real issue with the general 'tg depend rm' command. Almost. The real 'tg depend rm' (or maybe rather, 'tg depend fold' as in "this topic branch got folded to that branch") command would be slightly more complicated, I think, in order to ensure that no mysterious leftovers of the retired patch are lurking in your patch tree. Assuming tg depend fold RETIRED VANILLA (i) Take the RETIRED _base_ branch (ii) Merge in VANILLA (iii) Merge in RETIRED head branch with -s ours (iv) Now we have a commit that contains RETIRED topic branch, but with the RETIRED's changes taken from VANILLA instead of RETIRED (v) Merge this into the base of your current branch (vi) Merge base to the head of your current branch, replacing RETIRED with VANILLA (if not already there) in the .topdeps (vii) You do not have to add VANILLA if you depend on it recursively and ran tg update before to get it from your dependencies Maybe in your case this could be even simpler but this should be the general process. Does that sound right?
So, I've been hit badly by this, any news on a proper fix? In the interim, it would be good even to know a work-around. I was foolish enough to remove the remote branch after having issued a "tg delete" and now my repository at http://git.ocamlcore.org/cgi-bin/gitweb.cgi?p=batteries/batteries.git;a=summary is screwed, when I do a remote populate I get the following $ tg remote --populate origin tg: Remote origin can now follow TopGit topic branches. tg: Populating local topic branches from remote 'origin'... tg: Skipping branch debian/missing-doc: Already exists tg: Adding branch features/flexi-build... fatal: ambiguous argument 'origin/features/flexi-build': unknown revision or path not in the working tree. Use '--' to separate paths from revisions fatal: origin/features/flexi-build: not a valid SHA1 tg: The remote 'origin' is now the default source of topic branches. I've no fscking idea of where topgit on the remote repo has stored the "features/flexi-build" name. It is not in any .topdeps AFAIK. I would be happy with whatever hack that make topgit forget forever that branch name because it is not there anymore. Any suggested hack would be appreciated. Cheers.
Hello Stefano, Hhhm, the above repo doesn't seem to have the branches for debian/missing-doc, is it the right repo? Anyhow try this: git push origin :refs/top-bases/features/flexi-build Most of the time topgit gets an enumeration by looking at the top-bases. So the above command deletes the corresponding top-base for the failing branch. Best regards Uwe
My fault, before discovering this bug report I thought once I did "tg delete" I was allowed to delete the remote branch and I did that hackishly. No idea why topgit does not complain about that branch while it complains about features/flexi-build. Gotcha!, it worked, that's the trick to keep in mind to clean up until we have a proper solution to branch deletion, I guess. Thanks.
Hello Stefano,
I'm sure that the algorithm described by Pasky doesn't give you the
precondition to do tg delete $branch savely and that's why he called it
fold, not remove.
E.g. consider that I based a change on top of your features/flexi-build
and you don't know that. Now you do some magic transformation and in
the end remove your branch.
What should tg update do for me after that? Note that for step (v) in
Paskys algorithm I need your result from (iv)[1].
If you don't care about that you can simply tg-remove your branch of
course. That's analogous to rebase in core-git: If you have published
your work, your downstream people are out of luck.
Best regards
Uwe
[1] The only possible way is that you can only ever delete branches that
have some other branches depending on it. Then my tg update can
check if it finds the last version of the deleted branch in the
history of any of your current ones.
Hello Sitaram, But note that you might get some problems after doing that. See http://thread.gmane.org/gmane.comp.version-control.git/116193/focus=116205 for some more details. Best regards Uwe
also sprach martin f krafft <madduck@debian.org> [2009.05.09.1113 +0200]:
It turns out that remotely-deleted branches don't just get pushed
back, unless someone explicitly pushes them, or uses --all. Any
project needs a barrel of tar and many feathers for people who do
that without knowing what they're doing. A pre-update hook could be
used to permanently ban certain branch-names or refs from being
pushed back. Thus, the only persistent mess would be local, and
that's everyone's own responsibility.
The reason why the above might be a bit problematic with TopGit is
because TopGit adds a push ref to the configuration:
push = +refs/top-bases/*:refs/top-bases/*
push = +refs/heads/*:refs/heads/*
This overrides the default ':', which only pushes branches already
present remotely, and causes all local branches to be pushed. I've
been bitten by this plenty of times before.
We can only hope that Marc Weber's tg-push will allow us to get rid
of the push refs:
http://news.gmane.org/find-root.php?group=gmane.comp.version-control.git&article=117554
Ideally, git-push should be able to push associated branches, e.g.
any TopGit refs related to a branch it pushes, instead of
implementing and maintaining the same logic in tg-push. We'll see.
To recap: if TopGit learnt how to fold branches and retire them, and
it would also remove remote branches appropriately, *and* people
with push access could be trusted not to dumbly push them back (or
a hook preventing them from doing so), we'd have what we want.
Forgive my stupidity, but after reading this bug report I'm still not able to figure out how to retire a topgit branch that is no longer needed for a new upstream version. Should I tg-delete it, or will this mess things up? Cheers, Marcus
Hello Marcus, For one thing, something sensible happens automatically if upstream just took your branch: Your tg-branch gets empty. So the easiest solution is to keep this empty branch. If nothing depends on this branch, you can tg-delete it. Note that if your branch is public someone else might depend on it and you might mess things up for her if you delete it. And you must be aware that you delete history for older upstream versions. Best regards Uwe
-- Sayang Hari pengguna akun webmail, Akses online ke Akun login Anda hampir penuh berakhir, dan ini akan menyebabkan akun Anda akan dinonaktifkan. Silahkan pada link di bawah dan menyerahkan rincian Anda untuk keamanan dan update akun Anda Klik disini: http://webmailinfonetsecuritylogin.sitey.me [1] Terima kasih untuk menggunakan akun Webmail. Webmail Layanan Keamanan Links: ------ [1] http://webmailinfonetsecuritylogin.sitey.me/