Johannes Schindelin wrote:
> 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.
>> 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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
