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. -- Shawn. - 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
