Hi Duy, Looking closer at the rest of the docs, I guess it is consistent, but not terribly helpful. Throughout the docs (--help and man), it is never very clear what objects a command may accept or not. here is what I get from it: Whenever a command description involves "<branch>" this can, depending on the command, refer to 1) a name that, when prepended with "refs/heads/", is a valid ref, 2) a name that, when prepended with "refs/heads/" or "refs/tags", is a valid ref, 3) a name that, when prepended with "refs/[heads|tags]/", or unique in "refs/remotes/*/" is a valid ref Now in the docu I don't see a nice distinction between 1), 2) and 3). I could work on a patch if someone tells me how to clearly distinguish those cases. Example for 1) git clone --branch <branch> in git 1.7.x Example for 2) git clone --branch <branch> in git 1.8.x Example for 3) git checkout <branch> in git 1.8.x I would like the docs to relate to those e.g. as 1) git clone --branch <local-branch> 2) git clone --branch <local-branch-or-tag> 3) git checkout <commit-label> or something similar, in the future. But I wont create a patch before having some blessing on the labels to use. On a related note, what would help my use-case would be an extension to git clone such that git clone [--deep] accepted also most other kinds of commit references, such as SHA-IDs. Such that git clone --deep --branch 2h134vjvbc would work. Is there a plan to introduce that as well? cheers, Thibault On Mon, Feb 18, 2013 at 7:49 AM, Duy Nguyen <pclouds@xxxxxxxxx> wrote: > On Mon, Feb 18, 2013 at 2:13 AM, Thibault Kruse > <tibokruse@xxxxxxxxxxxxxx> wrote: >> Hi all, >> >> I notice that using git 1.8.3, I can call >> git clone repo1 repo2 --branch tagname >> with a tag, not a branch. Is this going to be a stable and documented feature? > > There is a test for --branch=tag in t5601, so I say it's supported. If > the document is not clear, patches are welcome. > -- > Duy -- 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