Re: [PATCH] Add platform-independent .git "symlink"

From: Brandon Casey <casey@nrlssc.navy.mil>
Date: Feb 5, 2008, 02:42 UTC
Message-ID: <47A7CD29.40306@nrlssc.navy.mil>
In-Reply-To: <alpine.LSU.1.00.0802050047340.8543@racer.site>

Johannes Schindelin wrote:

Show 10 quoted lines

> Hi,
> 
> On Mon, 4 Feb 2008, Brandon Casey wrote:
> 
>> When we talk about clones we are not always talking about a strict 
>> "full" clone.
> 
> Here, sir, we disagree.  I tend to like the fact that a clone is a clone 
> is a clone.  Which BTW is the reason why I do not like requests to "clone" 
> only one branch: this is not a clone.

It seems the git-clone utility has been extended to create more than just clones in that case.

My use of the term "clone" with respect to git, is to refer to the product of the git-clone utility. With that in mind, git-clone produces all of the repo/work-dir combinations I described.

The strict (or precise) definition of "clone" seems like a subset of the more generic "create new repository/workdir from existing repository". The different options then allow you to control how the new repo/workdir is structured.

We don't currently have a generic "create new repository/workdir from existing repository" command. So people have been using git-clone to create new repository/workdir's and calling the result clones, even though they could have produced the same result by running some sequence of mkdir, git init, and git pull.

Show 10 quoted lines

>> If your statement above is rephrased to "I _want_ the original 
>> repository to know that it has conjoined siblings.", then we have a new 
>> repository type:
>>
>> 	4) conjoined repository (it has multiple sibling repositories each
>> 	   with their own working directory, but they all share and modify the
>> 	   same .git directory)
> 
> No.  The repository does not even need a working directory (in which case 
> we call it "bare").

The additional term "bare" that is used with such a repository without a working directory implies to me that this is a "special" or "uncommon" repository configuration.

I think in many places in the documentation and it seems in common use on the mailing list, the contents of the directory created by git-clone is informally referred to as the repository. This is even though most people understand that the precise definition of repository is the .git directory and the rest of the contents are the working directory.

So I hope you excuse me for referring to the result of git-clone as a repository. I'll try to think of something else to call it (above I used repo/workdir).

None of that changes my opinion that a descent model for the user interface is to have two high-level commands that create repo/workdir's.

     git-init: creates a new repo/workdir from scratch.
    git-clone: creates a new repo/workdir from an existing repository.

Or the opinion that git-clone is a closer operation to creating a new working directory and associating it with a repository than either git-branch or git-checkout, which in normal usage (i.e. _not_ setting GIT_DIR or using --git-dir) operate within a working directory.

With that, I think I have described my thinking well enough, so I won't continue any more unless you really ask a question.

>  Up until now, it _can_ have _one_ working directory.  
> With my plans, it can have more than one.

I'm looking forward to your plans, since I find the git-new-workdir script very useful.

-brandon