On Tue, 13 Nov 2007, Shawn O. Pearce wrote: > Matthieu Moy <Matthieu.Moy@xxxxxxx> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
