TopGit: How to retire obsolete topic branches?
Manoj Srivastava
srivasta at acm.org
Sat May 9 22:28:05 UTC 2009
On Sat, May 09 2009, martin f krafft wrote:
> also sprach Stefano Zacchiroli <zack at 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.
Accumulate?
> 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:
Why not?
git checkout upstream
git checkout -b topic--obsolete-later
<develop>
git push --all
At this point, topic--obsolete-later and
origin/topic--obsolete-later exist.
Upstream abso\rbes the topic branch, so it is now obsolete.
git checkout topic--obsolete-later
git checkout -b old-obsolete-now
git push --all
git branch -d topic--obsolete-later
git push origin :topic--obsolete-later
git remote prune origin
Seems to me the topic--obsolete-later is pretty much retired.
> 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. :)
This sounds wrong to me. What am I missing?
manoj
--
Coward, n. one who in a perilous emergency thinks with his legs. Ambrose
Bierce
Manoj Srivastava <srivasta at acm.org> <http://www.golden-gryphon.com/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
More information about the vcs-pkg-discuss
mailing list