On Wednesday 31 January 2007, Carl Worth wrote:
> > It would be nice if:
> >
> > git clone -b ${branch} git://...
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.
> In addition, it would be great to have a command that did the same
> setup within an existing repository.
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.
> And I would be most happy if the two commands for these two use cases
> shared as much syntax as possible, so I could publish one string and
> users could cut-and-paste it to either command as appropriate.
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".
> One string I would have liked would have been "git://... ${branch}"
IMHO "-b" option is better as it tells you that it creates a new
local development branch for you.
Josef
> but existing git-clone and git-fetch command syntax is not too
> amenable for that, (git-clone interprets an argument after the URL as
> the name of the local directory to create while git-fetch interprets
> the argument after the URL as a refspec).
>
> -Carl
>
-
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