Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
quoted text
> 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.

-- 
Shawn.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html