Re: [RFD] making separate-remote layout easier to use

From: Shawn Pearce <spearce@spearce.org>
Date: Nov 26, 2006, 04:23 UTC
Message-ID: <20061126042311.GB30001@spearce.org>
In-Reply-To: <7vvel2yi2u.fsf@assigned-by-dhcp.cox.net>

Junio C Hamano <junkio@cox.net> wrote:

Show 22 quoted lines

> Shawn Pearce <spearce@spearce.org> writes:
> 
> > Needing to put + in front of a refspec (or needing to fetch it with
> > --force) is the user agreeing that something _evil_ is going on with
> > the upstream and that they acknowledge this may cause problems for
> > them locally.
> >
> > I would prefer to see the upstream be able to publish a short
> > description of each branch, where the repository owner can describe
> > the policy of that branch, as well as have a machine readable
> > setting on each branch indicating if that branch will be rewound
> > from time to time, or never rewound.
> >
> > git-clone should skip rewinding branches by default, unless the user
> > adds an option (e.g. --include-rewinding-branches).  This way new
> > users to git.git don't get the `pu` branch unless they really mean
> > to get it, at which point they have hopefully also read the upstream's
> > description of the `pu` branch and its rewinding policy, and can
> > at least start to grasp what is going to happen if they start to
> > work with the branch.
> 
> I like this approach very much.

I think the idea of glob'ing off the remote during clone (and using the glob for future fetches) is a good idea. So I think what I'm suggesting above is to make glob'ing by default not copy the rewinding branches, unless the glob spec itself starts with '+' (which is what say --include-rewriting-branches would do).

So now we're at a point of:

 * how do we get this branch information from the remote?
 * how does the remote store this branch information?

I'm leaning towards the repo config for the latter, with say:

	[branch "pu"]
		rewinds = true
		description = This branch contains some proposed updates to git.\n\
	It rewinds often, as different updates are proposed or merged into 'next'.

but looking at that think its rather horrible looking.  :-)

However for the former it may be useful if the client can download the repo config from the remote repository, such as to fetch the branch description data.