Re: [PATCH 07/16] git-read-tree: take --submodules option

From: Junio C Hamano <junkio@cox.net>
Date: May 21, 2007, 19:01 UTC
Message-ID: <7vr6pac86g.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20070521180506.GP942MdfPADPa@greensroom.kotnet.org>

Sven Verdoolaege <skimo@kotnet.org> writes:

Show 19 quoted lines

> On Mon, May 21, 2007 at 06:59:38PM +0200, Jan Hudec wrote:
>> We could store the GIT_DIR of submodule within the GIT_DIR of the
>> superproject instead of the submodule directory itself. So instead of:
>>  /
>>  /.git
>>  /subdir
>>  /subdir/.git
>> 
>> There would be:
>>  /
>>  /.git
>>  /subdir
>>  /.git/submodules/submodule-name.git
>
> I have this already, except that I use /.git/submodules/submodule-name/.git
> because I was too lazy to figure out how to get clone to use the above
> without using --bare, because --bare disables separate-remotes.
>
> Is there any good reason, btw for --bare not to do separate-remotes ?

Traditinoally, the purpose of --bare is to set up distribution points, either CVS style "shared public repository that everybody pushes into and fetches from", or "owned by me and I push my change into it to publish". In either case, there is no point of even having an upstream in such a repository, let alone refs/remotes/origin/ hierarchy.

So that's the "good reason" part.

Having said that, last night I was thinking about making the layout after a clone a bit more flexible and orthogonal to existence of working tree. What got me thinking about it was different from your motivation, though.

If you have an ordinary working tree, and if you want to have a clone of that working tree that you can work in, independently (i.e. not treating the repository you cloned from any specially from other repositories by marking it "origin"), currently there is no straightforward way to do so, other than doing something like:

 (1) do a --bare clone, which would create "project.git";

 (2) mkdir "project" && mv "project.git" "project/.git";

 (3) edit "project/.git/config" and mark it as a non-bare
     repository.

 (4) "git checkout -f HEAD".

I'd call this a "pure" clone. It is as close as the original repository you would get without copying other per-repository data such as .git/info, .git/config, so that you can start using it as an _independent _repository. It is like a --bare clone but with a working tree associated with it.

What you want is probably the opposite. A bare, but non-pure clone. By non-pure, what I mean is:

 (1) it has an upstream ("origin"), hence
 (2) it has refs/remotes/origin, and "remotes.origin.*"

If the word "non-pure" has a negative connotation, you could call it "a follower repository".

In short, the current behaviour of --bare is "bare and pure", and clone without --bare is "not bare, and a follower". What I wanted was "not bare, but pure", and I think what you want is "bare, but a follower".