On Sat, May 09, 2009 at 11:13:17AM +0200, martin f krafft wrote:
> also sprach Stefano Zacchiroli <z...@debian.org> [2009.05.07.1902 +0200]:
> > When I, as a newcomer of a given repo, do "git tag" I know I'm
> > looking at a lot of "not current" information. On the contrary,
> > when I do "git branch" I start trying figure out what each branch
> > means. Having around a lot of no longer used branches is very
> > annoying in that respect.
> Keep in mind that the branches accumulate remotely, so you'd have to
> pass -r or -a to git-branch to be exposed to them.
> Obviously, any curious newcomer will do that, but then, a sane
> convention like Manoj hinted at will help, because you'd have to be
> amazingly curious to realy wonder about branches in the obsolete/*
> namespace.
> Anyway, unfortunately, published branches cannot be renamed with
> Git, or retired, or anything of that sort, so the concern is valid:
> you'd have to start a new feature branch as obsolete/new-feature to
> be able to declare it obsolete later on, at which point we might
> just as well not use the namespace. :)
> I see two required steps to solve this:
> a. teach TopGit how to retire branches, as per debbug#505303
> b. teach Git how to retire/rename published branches
> I'll think about (b) for a bit and see if this wouldn't make sense
> to be raised with the Git people. Comments welcome, of course.

You can do `git remote prune` to get rid of branches that disappeared
upstream. Hypothetical `tg retire` (a stupid name, of course) would
do git branch -d branch and git push origin :branch :refs/bases/branch.
`tg update` or some other command would then have to do the `git remote
prune` part and have some fancy logic to retire the branches locally
too if there are no changes in them. The case when there are local
changes in the retired branches is left as an exercise for the reader.

                                Petr "Pasky" Baudis
The lyf so short, the craft so long to lerne. -- Chaucer

vcs-pkg-discuss mailing list

Reply via email to