Nice indeed.
Additionally, it would be nice for clone to directly
checkout tags. Why not an option "--checkout <ref>"
to directly checkout <ref> after cloning?
This goes nicely with the "-b" option
to create a new branch. A "-b <branch>" option alone would
imply "--checkout origin/<branch>". And without "--checkout"
or "-b" option it defaults to "-b master" which gives
exactly the same behavior as now.
This way,
git clone --checkout v1.0 git://...
would checkout tag v1.0, and use a detached head for it.
Why not use "git clone" for this?
Currently, the man page says about the directory it will clone into:
"Cloning into an existing directory is not allowed."
But we could relax this: if the specified directory is the root of
a checkout (ie. with a .git subdir), we would clone a remote repository
into the same local repository. However, this should not default
to "-b master", ie. not switch the current branch. Additionally, the
remote name should not default to "origin", but to the
"humanish" part of the source repository. IMHO we should have done
the latter since long time ago, as a remote "origin" is not really
useful once you work with branches from multiple remote repositories.
Doing this,
git clone git://... <newdir>
would be the equivalent of
mkdir <newdir>
cd <newdir>
git init
git clone -b master git://... .
which IMHO would make a lot of sense.
You would say:
"To get version <xyz>, do a
git clone --checkout <xyz> git://...
If you already have a local clone of the repository, append the
directory of your local repository as target to clone this version
into".
IMHO "-b" option is better as it tells you that it creates a new
local development branch for you.
Josef
-
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