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

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