Re: [PATCH/RFC] Allow "git remote --mirror" to mirror stashes

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 31, 2008, 00:19 UTC
Message-ID: <7vve33vj7a.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <alpine.LNX.1.00.0803281124240.19665@iabervon.org>

Daniel Barkalow <barkalow@iabervon.org> writes:

> On Thu, 27 Mar 2008, Junio C Hamano wrote:
>
> Maybe it shouldn't do any filtering here, and instead do it in 
> cmd_fetch_pack?

I dunno.  How would the code look like?

Show 5 quoted lines

> This is also true, although I'm not too sure that we won't want to do 
> things like having "refs/default" in a public repository be the 
> repository's suggestion for the default branch (to replace "HEAD", 
> because, in a world where people use lots of branches, the "current 
> branch" idea and the "default branch" idea aren't really the same idea,

In a public repository with many branches to serve people with different interests, I do not think a single refs/default in addition to HEAD would help that much. We would _not_ want to have more magic refs like HEAD.

Quite the opposite. In such a repository, HEAD means even less, and instead of giving an extra layer of indirection, you tell people which branches are what in your repository. "If you are interested in only the bugfixes without any new features since the last feature lease no matter how solid and tested they are, use 'maint' branch. If you want solid and tested features, and do not mind new features, use 'master'. Etc.".

And just like a good API names its functions sensibly, you give meaningful names to your branches, so that you do not _need_ that extra layer of indirection refs/default would incur.