Re: Trying to Update All Heads of a Repository

From: Junio C Hamano <junkio@cox.net>
Date: Nov 5, 2005, 02:07 UTC
Message-ID: <7v64r7sv7o.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.64.0511041745480.25300@iabervon.org>

Daniel Barkalow <barkalow@iabervon.org> writes:

> Shouldn't approximately this be what git-clone sets up for you? If it's 
> getting those heads initially, it should keep the information for future 
> use. The only thing it wouldn't know would be the "+" on pu.

Yes, and I am actually thinking along the lines of:

         URL: git://git.kernel.org/pub/scm/git/git.git
         Pull: master:origin/master
         Pull: +pu:origin/pu
         Pull: maint:origin/maint

to further prevent the puller's namespace being cluttered. This has an added benefit that it gives a convention that "remotes/origin" file describes the "refs/heads/origin" hierarchy. In the past, somebody complained that branches/* files are configuration per local branch, but remotes/* files are not.

Show 5 quoted lines

> On the "pu" issue, maybe "pu" shouldn't be a branch, but should be 
> something different, like a tag. I think, actually, that a tag would 
> describe "pu" pretty well: no development happens on its line; rather, 
> development happens elsewhere (topic branches), and a merge of some of 
> them is then released as being interesting.

Hmph.  That is a thought.

Another thing that bothers me somewhat about git.git/ repository is the todo branch. The "todo" branch does not have any common commit from the mainline and it is deliberately so --- I'd want to maintain a unified TODO list even after we go 1.0, at that time I plan to have master that continues post 1.0 development, maint which corresponds the current maint (i.e. maintenance for post 1.0 releases) and maint1.0 which is for backporting important fixes to frozen 1.0. I could maintain separate TODO-for-post-1.0 and TODO-for-1.0-maint, but that is rather a waste --- items on the two list both end up requirign attention and time from the same brain. Also merging "todo" into master and maint1.0 the way "gitk" project was merged into git.git would not make much sense, because that merge is pretty much one-way street.

The first thing I clone from git.git/ repository is almost always "rm -f .git/refs/heads/todo", because it clutters git-show-branch output otherwise ;-). In fact, it comes from totally separate repository on my private end, and just happens to be pushed into the same git.git/ repository (partly because I do not have any other repository there at kernel.org; i.e. /pub/scm/git/ is not writable by me).