Re: Cloning empty repositories, was Re: What is the idea for bare repositories?

On Tue, 13 Nov 2007, Shawn O. Pearce wrote:

Matthieu Moy [off-list ref] wrote:

quoted

I repeat the use-case I mentionned above :

,----
| a typical use-case is when I want to create a new project. I'd
| like to initialize an empty bare repo on my backed up disk, and then
| clone it to my local-fast-unreliable disk to get a working copy and do
| the first commit there.
`----

I find this quite natural, and up to now, no one gave me either a
rationale not to do that, or a _simple_ way to achieve this. As I
said, it's currently not _very_ hard to do, but I have to edit
.git/config by hand, while git clone knows how to do this much faster
than I for non-empty repositories.

Its a goal to redefine git-clone as the following, as that is
really all it does:

	mkdir foo && cd foo && git init &&
	git remote add -f origin $url &&
	git checkout -b master origin/master

So setting up an empty tree is basically that:

	mkdir foo && cd foo && git init &&
	git remote add origin $url

Is that really so difficult?  git-clone is a handy crutch for when
we didn't have things like git-remote.  Or remote tracking branches.
IMHO the above may seem a little low level but it may make it easier
to teach to newbies.  They are more likely to grasp the concept of
their repository being just like someone else's, and that they can
track other repositories beyond just their origin.

FWIW all my Git tutorials for $work so far always avoided 'git clone'. 
The 'git init' + 'git remote add' + 'git fetch' is what I ask people to 
do.  It is more obvious to give a good name for the remote repo that 
way, and this can be performed into either a new or an existing repo 
when the data is related.


Nicolas