[PATCH] add --remote option to git-clone.

[PATCH] add --remote option to git-clone.

[Michael S. Tsirkin]

It is sometimes useful to track, and develop against, a single
topic branch from the remote repository.
Make this easier to do by adding a flag to git-clone.

Signed-off-by: Michael S. Tsirkin <mst@mellanox.co.il>

---

We have a repository with several long-lived topic branches.

I'm often annoyed by the fact that when I clone from this repository,
I get a copy of all topic branches and origin tracking master
by default, when I actually might only want to work on a different
topic. And getting all extra branches is annoying on a slow connection.

So here's the patch to only get a single branch on clone.
Other branches can be added later, on demand.

Junio, what do you think?
I would like very much for git to support this capability.

diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index 707376f..f66a969 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -10,8 +10,8 @@ SYNOPSIS
 --------
 [verse]
 'git-clone' [--template=<template_directory>] [-l [-s]] [-q] [-n] [--bare]
-	  [-o <name>] [-u <upload-pack>] [--reference <repository>]
-	  [--depth=<depth>] <repository> [<directory>]
+	  [-o <name>] [-u <upload-pack>] [--remote <remote-branch>]
+	  [--reference <repository>] [--depth=<depth>] <repository> [<directory>]
 
 DESCRIPTION
 -----------
@@ -84,6 +84,10 @@ OPTIONS
 	Instead of using the remote name 'origin' to keep track
 	of the upstream repository, use <name> instead.
 
+--remote <remote-branch>::
+	When given, only the specified remote branch will be
+	tracked; if unset all remote branches are tracked.
+
 --upload-pack <upload-pack>::
 -u <upload-pack>::
 	When given, and the repository to clone from is handled
diff --git a/git-clone.sh b/git-clone.sh
index 4ddfa77..b0fe7d1 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -14,7 +14,7 @@ die() {
 }
 
 usage() {
-	die "Usage: $0 [--template=<template_directory>] [--reference <reference-repo>] [--bare] [-l [-s]] [-q] [-u <upload-pack>] [--origin <name>] [--depth <n>] [-n] <repo> [<dir>]"
+	die "Usage: $0 [--template=<template_directory>] [--reference <reference-repo>] [--bare] [-l [-s]] [-q] [-u <upload-pack>] [--remote <remote-branch>] [--origin <name>] [--depth <n>] [-n] <repo> [<dir>]"
 }
 
 get_repo_base() {
@@ -78,6 +78,8 @@ reference=
 origin=
 origin_override=
 use_separate_remote=t
+remote_branch=
+all_remote_branches="--all"
 depth=
 while
 	case "$#,$1" in
@@ -104,6 +106,10 @@ while
 		shift; reference="$1" ;;
 	*,--reference=*)
 		reference=`expr "z$1" : 'z--reference=\(.*\)'` ;;
+	*,--remote)
+		remote_branch="$2"
+		all_remote_branches=
+	       	shift ;;
 	*,-o|*,--or|*,--ori|*,--orig|*,--origi|*,--origin)
 		case "$2" in
 		'')
@@ -227,7 +233,7 @@ yes,yes)
 	    echo "$repo/objects" >> "$GIT_DIR/objects/info/alternates"
 	    ;;
 	esac
-	git-ls-remote "$repo" >"$GIT_DIR/CLONE_HEAD" || exit 1
+	git-ls-remote "$repo" $remote_branch >"$GIT_DIR/CLONE_HEAD" || exit 1
 	;;
 *)
 	case "$repo" in
@@ -261,7 +267,7 @@ yes,yes)
 		    done
 		    rm -f "$GIT_DIR/TMP_ALT"
 		fi
-		git-ls-remote "$repo" >"$GIT_DIR/CLONE_HEAD" || exit 1
+		git-ls-remote "$repo" $remote_branch >"$GIT_DIR/CLONE_HEAD" || exit 1
 		;;
 	https://*|http://*|ftp://*)
 		case "$depth" in
@@ -277,8 +283,8 @@ yes,yes)
 		;;
 	*)
 		case "$upload_pack" in
-		'') git-fetch-pack --all -k $quiet $depth "$repo" ;;
-		*) git-fetch-pack --all -k $quiet "$upload_pack" $depth "$repo" ;;
+		'') git-fetch-pack $all_remote_branches -k $quiet $depth "$repo" $remote_branch;;
+		*) git-fetch-pack $all_remote_branches -k $quiet "$upload_pack" $depth "$repo" $remote_branch;;
 		esac >"$GIT_DIR/CLONE_HEAD" ||
 			die "fetch-pack from '$repo' failed."
 		;;
@@ -304,6 +310,9 @@ then
 			continue ;;
 		HEAD)
 			destname="REMOTE_HEAD" ;;
+		refs/heads/$remote_branch)
+			git-update-ref -m "clone: from $repo" "REMOTE_HEAD" "$sha1" ""
+			destname="refs/$branch_top/${name#refs/heads/}" ;;
 		refs/heads/*)
 			destname="refs/$branch_top/${name#refs/heads/}" ;;
 		refs/tags/*)
@@ -334,25 +343,32 @@ then
 	esac
 
 	# The name under $remote_top the remote HEAD seems to point at.
-	head_points_at=$(
-		(
-			test -f "$GIT_DIR/$remote_top/master" && echo "master"
-			cd "$GIT_DIR/$remote_top" &&
-			find . -type f -print | sed -e 's/^\.\///'
-		) | (
-		done=f
-		while read name
-		do
-			test t = $done && continue
-			branch_tip=`cat "$GIT_DIR/$remote_top/$name"`
-			if test "$head_sha1" = "$branch_tip"
-			then
-				echo "$name"
-				done=t
-			fi
-		done
+	if
+		test $remote_branch
+	then
+		head_points_at=$remote_branch
+		head_sha1=`cat "$GIT_DIR/REMOTE_HEAD"`
+	else
+		head_points_at=$(
+			(
+				test -f "$GIT_DIR/$remote_top/master" && echo "master"
+				cd "$GIT_DIR/$remote_top" &&
+				find . -type f -print | sed -e 's/^\.\///'
+			) | (
+			done=f
+			while read name
+			do
+				test t = $done && continue
+				branch_tip=`cat "$GIT_DIR/$remote_top/$name"`
+				if test "$head_sha1" = "$branch_tip"
+				then
+					echo "$name"
+					done=t
+				fi
+			done
+			)
 		)
-	)
+	fi
 
 	# Write out remote.$origin config, and update our "$head_points_at".
 	case "$head_points_at" in
@@ -368,11 +384,18 @@ then
 		git-config remote."$origin".url "$repo" &&
 
 		# Set up the mappings to track the remote branches.
-		git-config remote."$origin".fetch \
-			"+refs/heads/*:$remote_top/*" '^$' &&
-		rm -f "refs/remotes/$origin/HEAD"
-		git-symbolic-ref "refs/remotes/$origin/HEAD" \
-			"refs/remotes/$origin/$head_points_at" &&
+		(if
+			test $remote_branch
+		then
+			git-config remote."$origin".fetch \
+				"+refs/heads/$remote_branch:$remote_top/$remote_branch" '^$'
+		else
+			git-config remote."$origin".fetch \
+				"+refs/heads/*:$remote_top/*" '^$' &&
+			rm -f "refs/remotes/$origin/HEAD"
+			git-symbolic-ref "refs/remotes/$origin/HEAD" \
+				"refs/remotes/$origin/$head_points_at"
+		fi)
 
 		git-config branch."$head_points_at".remote "$origin" &&
 		git-config branch."$head_points_at".merge "refs/heads/$head_points_at"

-- 
MST

Re: [PATCH] add --remote option to git-clone.

[J. Bruce Fields]

On Fri, Feb 02, 2007 at 12:01:22AM +0200, Michael S. Tsirkin wrote:
> I'm often annoyed by the fact that when I clone from this repository,
> I get a copy of all topic branches and origin tracking master
> by default, when I actually might only want to work on a different
> topic. And getting all extra branches is annoying on a slow connection.

Can you quantify "annoying"?

Not a challenge, I'm just curious--I would've thought that, for most
projects, even with long-lived topic branches, it wouldn't be that
expensive to get a second branch once you'd gotten one.

--b.

Re: [PATCH] add --remote option to git-clone.

[Shawn O. Pearce]

"J. Bruce Fields" <bfields@fieldses.org> wrote:
> On Fri, Feb 02, 2007 at 12:01:22AM +0200, Michael S. Tsirkin wrote:
> > I'm often annoyed by the fact that when I clone from this repository,
> > I get a copy of all topic branches and origin tracking master
> > by default, when I actually might only want to work on a different
> > topic. And getting all extra branches is annoying on a slow connection.
> 
> Can you quantify "annoying"?
> 
> Not a challenge, I'm just curious--I would've thought that, for most
> projects, even with long-lived topic branches, it wouldn't be that
> expensive to get a second branch once you'd gotten one.

Not true; I work on projects like that and some of the branches
are several MiB of additional objects beyond the other branches.
It can add up very, very fast.

Over slow corporate VPN connections this is definately a problem.
Usually the user only wants one branch *right now*.  Getting another
15 MiB of data for branches which they aren't interested in could
take another 5 minutes.  If they do need those, they could always
fetch the additional branches later, or do it from the office where
the network doesn't suck.

-- 
Shawn.

Re: [PATCH] add --remote option to git-clone.

[Michael S. Tsirkin]

> Quoting J. Bruce Fields <bfields@fieldses.org>:
> Subject: Re: [PATCH] add --remote option to git-clone.
> 
> On Fri, Feb 02, 2007 at 12:01:22AM +0200, Michael S. Tsirkin wrote:
> > I'm often annoyed by the fact that when I clone from this repository,
> > I get a copy of all topic branches and origin tracking master
> > by default, when I actually might only want to work on a different
> > topic. And getting all extra branches is annoying on a slow connection.
> 
> Can you quantify "annoying"?
> 
> Not a challenge, I'm just curious--I would've thought that, for most
> projects, even with long-lived topic branches, it wouldn't be that
> expensive to get a second branch once you'd gotten one.

Shawn already answered that, I concur.

-- 
MST

Re: [PATCH] add --remote option to git-clone.

[Johannes Schindelin]

Hi,

would this option not be better named "--branch"? Of course, you'd have to 
support this, too:

	$ git clone --branch topic1 --branch topic2 git://...

Ciao,
Dscho

Re: [PATCH] add --remote option to git-clone.

[Shawn O. Pearce]

Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> would this option not be better named "--branch"? Of course, you'd have to 
> support this, too:
> 
> 	$ git clone --branch topic1 --branch topic2 git://...

Yes, --branch sounds better here.

-- 
Shawn.

Re: [PATCH] add --remote option to git-clone.

[Yann Dirson]

On Thu, Feb 01, 2007 at 05:06:57PM -0500, J. Bruce Fields wrote:
> On Fri, Feb 02, 2007 at 12:01:22AM +0200, Michael S. Tsirkin wrote:
> > I'm often annoyed by the fact that when I clone from this repository,
> > I get a copy of all topic branches and origin tracking master
> > by default, when I actually might only want to work on a different
> > topic. And getting all extra branches is annoying on a slow connection.
> 
> Can you quantify "annoying"?
> 
> Not a challenge, I'm just curious--I would've thought that, for most
> projects, even with long-lived topic branches, it wouldn't be that
> expensive to get a second branch once you'd gotten one.

Regardless of the extra branches, it is also annoying to have the
master branch in the clone branched off the HEAD of the parent repo.
Especially when you intend to fork an stgit stack off the non-HEAD
branch - it will be a pleasure to make "stg clone" to take advantage
of this new feature :)

This is also a feature which is available in cogito since ages
(cg-clone URL#branch), and not having it in plain git is an annoyance.

Best regards,
-- 
Yann.

Re: [PATCH] add --remote option to git-clone.

[Michael S. Tsirkin]

> Quoting Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> Subject: Re: [PATCH] add --remote option to git-clone.
> 
> Hi,
> 
> would this option not be better named "--branch"?

OK

> Of course, you'd have to 
> support this, too:
> 
> 	$ git clone --branch topic1 --branch topic2 git://...

Why is this useful? and which branch to check out?
One can always get more branches later, is my approach.

-- 
MST

Re: [PATCH] add --remote option to git-clone.

[Johannes Schindelin]

Hi,

On Fri, 2 Feb 2007, Michael S. Tsirkin wrote:

> > Quoting Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> > Subject: Re: [PATCH] add --remote option to git-clone.
> > 
> > Of course, you'd have to 
> > support this, too:
> > 
> > 	$ git clone --branch topic1 --branch topic2 git://...
> 
> Why is this useful?

For the same reasons it might be useful to track _all_ branches.

> and which branch to check out?

I'd say the first, but that's just my opinion.

> One can always get more branches later, is my approach.

Yes. But in the same vein, one can add _one_ branch to an empty repo 
either. So, with your reasoning, your patch wouldn't be needed to begin 
with.

But I find it useful. Even the version where you are not limited to one 
branch.

Ciao,
Dscho

Re: [PATCH] add --remote option to git-clone.

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> On Fri, 2 Feb 2007, Michael S. Tsirkin wrote:
> ...
>> One can always get more branches later, is my approach.
>
> Yes. But in the same vein, one can add _one_ branch to an empty repo 
> either. So, with your reasoning, your patch wouldn't be needed to begin 
> with.

Indeed.

> But I find it useful. Even the version where you are not limited to one 
> branch.

I am not against the general idea of tracking a subset of
branches, but issues include:

 [1] tracking multiple (but not all) branches, as you pointed out,

 [2] how this should interact with later fetches from the same
     remote.

 [3] allowing similar "track these branches from a new remote
     from now on" in an already initialized repository.

Perhaps by specifying the --branch parameter in an wildcard
fashion, remote.*.fetch can be initialized to that wildcard and
later new branches that match the wildcard pattern ca be fetched
(which is a strawman solution for [1] and [2]).  I suspect [3]
belongs to what "git remote" should allow you to do, but in that
case maybe "git init-db ; git remote *that-new-command*" would
be a single uniform way to solve all of the above?

I personally feel this is post 1.5.0 material.

Re: [PATCH] add --remote option to git-clone.

[Johannes Schindelin]

Hi,

On Thu, 1 Feb 2007, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > On Fri, 2 Feb 2007, Michael S. Tsirkin wrote:
> > ...
> >> One can always get more branches later, is my approach.
> >
> > Yes. But in the same vein, one can add _one_ branch to an empty repo 
> > either. So, with your reasoning, your patch wouldn't be needed to begin 
> > with.
> 
> Indeed.
> 
> > But I find it useful. Even the version where you are not limited to one 
> > branch.
> 
> I am not against the general idea of tracking a subset of
> branches, but issues include:
>
> [explains why git-remote is a better place for this]

Seeing your patch to git-remote, it feels more natural, too. Especially 
since that (or which? :-D) does not give the term "clone" a 
Microsoft'esque completely new meaning.

Ciao,
Dscho

Re: [PATCH] add --remote option to git-clone.

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> On Thu, 1 Feb 2007, Junio C Hamano wrote:
> ...
>> I am not against the general idea of tracking a subset of
>> branches, but issues include:
>>
>> [explains why git-remote is a better place for this]
>
> Seeing your patch to git-remote, it feels more natural, too. Especially 
> since that (or which? :-D) does not give the term "clone" a 
> Microsoft'esque completely new meaning.

I did not find anything MS'esque in what MST did in his patch,
though.  I think it is a reasonable thing to ask for from a
clone.  For example, if you are coming from CVS or have used
Cogito, cloning a single branch is not an unusual operation at
all.

The real point of my 'remote add -f -t -m' patch is that I think
we are much better off to do it in a bottom up way, by having a
tool that can be used in any repository first.  Then we could
even rewrite 'git clone' along these lines:

	#/bin/sh
	track="*" ;# command line parameter to override...
	... decide what $name to use ...
	mkdir "$name"
	cd "$name"
	git init-db
        git remote add -f -t "$track" origin $url
	git branch -f master remotes/origin/master

Of course you would need to deal with -n, --bare and stuff, but
that is a minor detail.

While I am talking about post 1.5.0 git-clone changes, one thing
I've always hated about git-clone is that the cloner always has
to guess where the HEAD pointer at the other side points at.
This comes from a shortcoming in the fetch-pack protocol (it
simply does not tell).  A stupid consequence of this is that
cloning over dumb protocols also have to guess, although they
are _capable_ of letting the cloner know this information.

I think the logic to decide where to point remotes/$origin/HEAD
to should be moved to "git-remote add -m" when we eventually
rewrite "git-clone" to use "git-remote add -f".  And while we
would do so, we can make a trivial extension to fetch-pack
protocol to carry the HEAD symref information.  All will be
good once that happens.

Re: [PATCH] add --remote option to git-clone.

[Jakub Narebski]

Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
>> On Thu, 1 Feb 2007, Junio C Hamano wrote:
>> ...
>>> I am not against the general idea of tracking a subset of
>>> branches, but issues include:
>>>
>>> [explains why git-remote is a better place for this]
>>
>> Seeing your patch to git-remote, it feels more natural, too. Especially 
>> since that (or which? :-D) does not give the term "clone" a 
>> Microsoft'esque completely new meaning.
> 
> I did not find anything MS'esque in what MST did in his patch,
> though.  I think it is a reasonable thing to ask for from a
> clone.  For example, if you are coming from CVS or have used
> Cogito, cloning a single branch is not an unusual operation at
> all.

But when we clone whole repository we could have download whole
object database of cloned repo as-is (perhaps packing loose objects
in smart/git-aware transports).

By the way, there was discussed idea about marking pu-like branches
as being rewound (non-fast forwarding) in the config file, and somehow
transferring this information for git-clone for it to have '+' for
some refspecs. What happened to that idea? Was it abandoned because
reflogs are now enabled by default, are protected from pruning, and
it is easy to recover from accidental non-fast forward fetch which
shouldn't be?

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: [PATCH] add --remote option to git-clone.

[Junio C Hamano]

Jakub Narebski <jnareb@gmail.com> writes:

>> I did not find anything MS'esque in what MST did in his patch,
>> though.  I think it is a reasonable thing to ask for from a
>> clone.  For example, if you are coming from CVS or have used
>> Cogito, cloning a single branch is not an unusual operation at
>> all.
>
> But when we clone whole repository we could have download whole
> object database of cloned repo as-is (perhaps packing loose objects
> in smart/git-aware transports).

I think your point is if you have branches A and B, cloning A+B
as a whole is a lot less expensive than cloning A and then B
separately.  While that is true, I do not think that reasoning
would apply to somebody, especially behind a slow link, who is
only interested in A.  She does not want to pay the cost of A+B,
when she only wants A, even if A+B is much less expensive than
twice the cost of getting A.

Also, if she later gets interested in B, git fetch will make the
"what's common" optimization.  It won't be like cloning A and
then fetching B into the same repository later would be twice as
expensive compared to the case where you start from a clone as a
whole.  The overall transfer cost would probably be comparable.

> By the way, there was discussed idea about marking pu-like branches
> as being rewound (non-fast forwarding) in the config file, and somehow
> transferring this information for git-clone for it to have '+' for
> some refspecs. What happened to that idea? Was it abandoned...

Well, I would not call some idle talk without a concrete design
(preferably with a proof-of-concept code, but that is not an
absolute requirement) "idea".  Something that did not even start
cannot get abandoned ;-).

I thought that it would not hurt to have something like that,
but because in 1.5.0 "git clone" creates fetch configuration of
'forcing' kind by default, I do not think it makes that much of
a difference.

Re: [PATCH] add --remote option to git-clone.

[Johannes Schindelin]

Hi,

On Fri, 2 Feb 2007, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > On Thu, 1 Feb 2007, Junio C Hamano wrote:
> > ...
> >> I am not against the general idea of tracking a subset of
> >> branches, but issues include:
> >>
> >> [explains why git-remote is a better place for this]
> >
> > Seeing your patch to git-remote, it feels more natural, too. 
> > Especially since that (or which? :-D) does not give the term "clone" a 
> > Microsoft'esque completely new meaning.
> 
> I did not find anything MS'esque in what MST did in his patch, though.  
> I think it is a reasonable thing to ask for from a clone.  For example, 
> if you are coming from CVS or have used Cogito, cloning a single branch 
> is not an unusual operation at all.

Oh? Well, to me, "clone" meant something like the genetics thing, i.e. get 
a copy of the repository. Since a "branch" is not the complete repository, 
but only part of it, I would have expected "engraft" instead of "clone" 
there.

But I can learn! So (post-1.5.0, maybe?) I'd be perfectly d'accord with 
something like this

	git clone git://.../git.git#html

to mean "just fetch the branch html, and check it out".

> The real point of my 'remote add -f -t -m' patch is that I think we are 
> much better off to do it in a bottom up way, by having a tool that can 
> be used in any repository first.  Then we could even rewrite 'git clone' 
> along these lines:
> 
> 	#/bin/sh
> 	track="*" ;# command line parameter to override...
> 	... decide what $name to use ...
> 	mkdir "$name"
> 	cd "$name"
> 	git init-db
>         git remote add -f -t "$track" origin $url
> 	git branch -f master remotes/origin/master
> 
> Of course you would need to deal with -n, --bare and stuff, but
> that is a minor detail.

Yeah, that makes sense.

> While I am talking about post 1.5.0 git-clone changes, one thing I've 
> always hated about git-clone is that the cloner always has to guess 
> where the HEAD pointer at the other side points at. This comes from a 
> shortcoming in the fetch-pack protocol (it simply does not tell).  A 
> stupid consequence of this is that cloning over dumb protocols also have 
> to guess, although they are _capable_ of letting the cloner know this 
> information.
> 
> I think the logic to decide where to point remotes/$origin/HEAD to 
> should be moved to "git-remote add -m" when we eventually rewrite 
> "git-clone" to use "git-remote add -f".  And while we would do so, we 
> can make a trivial extension to fetch-pack protocol to carry the HEAD 
> symref information.  All will be good once that happens.

Would you like this as a multi_ack-like extension?

But then how to teach the dumb protocols in a backwards-compatible 
fashion?

Ciao,
Dscho

Re: [PATCH] add --remote option to git-clone.

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> Oh? Well, to me, "clone" meant something like the genetics thing, i.e. get 
> a copy of the repository. Since a "branch" is not the complete repository, 
> but only part of it, I would have expected "engraft" instead of "clone" 
> there.
>
> But I can learn! So (post-1.5.0, maybe?) I'd be perfectly d'accord with 
> something like this
>
> 	git clone git://.../git.git#html
>
> to mean "just fetch the branch html, and check it out".

I agree that the word "clone" to me sounds like "copy the whole
repo", so a single branch cloning feels it is something
different from "clone", but I do not think it means wholeness
must be the only mode of operation.

Except that I do not particularly think the URL fragment
notation is such a "cool" syntax.

>> I think the logic to decide where to point remotes/$origin/HEAD to 
>> should be moved to "git-remote add -m" when we eventually rewrite 
>> "git-clone" to use "git-remote add -f".  And while we would do so, we 
>> can make a trivial extension to fetch-pack protocol to carry the HEAD 
>> symref information.  All will be good once that happens.
>
> Would you like this as a multi_ack-like extension?
>
> But then how to teach the dumb protocols in a backwards-compatible 
> fashion?

I am not talking about enhancing ls-remote output nor info/refs
file format.  I do not think we need to do anything special to
support it in backwards compatible way.

Look at what dumb protocols do in git-clone.  http already knows
where HEAD points at when it fetches HEAD with curl.  I do not
particularly care about rsync, but I suspect it can be handled
the same way.

Re: [PATCH] add --remote option to git-clone.

[Linus Torvalds]

On Mon, 5 Feb 2007, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> >
> > 	git clone git://.../git.git#html
> >
> > to mean "just fetch the branch html, and check it out".
> 
> Except that I do not particularly think the URL fragment
> notation is such a "cool" syntax.

I think the cogito '#'<branch> syntax is braindead.

Much better to use native git syntax, which is to just list the branch 
separately. Why? Not only is it the way we do things for pull and friends, 
it's also what allows us to specify *multiple* branches.

So I would personally welcome a "clone just a particular branch", but in 
that case I'd like it to be able to say more than one too..

(In general, even if I clone _everything_, I'd also like to perhaps set 
the default 'master' branch to track something else than what I'm cloning 
from. In fact, I think I'd generally prefer cloning everything, but 
sometimes I'd like to say "I'm going to track the upstreams branch xyzzy 
rather than their default branch").

I realize that the

	git clone <repo> [<dir>]

means that we can't have the same syntax as "git pull" (which doesn't take 
the <dir> part), but that doesn't make the "#branch" syntax any better.

So I much prefer the

	git clone [--default branch] [--branch x]* <repo> [<dir>

kind of syntax.

			Linus

Re: [PATCH] add --remote option to git-clone.

[Michael S. Tsirkin]

> Junio C Hamano <junkio@cox.net> writes:
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> > 	git clone git://.../git.git#html
> >
> > to mean "just fetch the branch html, and check it out".
>
> Except that I do not particularly think the URL fragment
> notation is such a "cool" syntax.

OK, but I think it would be very good I think to have *some* URL-like syntax for
git-fetch etc - people are used to copying URLs out of mail (lots of MUAs even
highlight these nicely) so I often see that current syntax <URL> <branch> confuses
people: they seem to lose the branch and fetch/pull the wrong one.


-- 
MST

Re: [PATCH] add --remote option to git-clone.

[Michael S. Tsirkin]

> (In general, even if I clone _everything_, I'd also like to perhaps set 
> the default 'master' branch to track something else than what I'm cloning 
> from. In fact, I think I'd generally prefer cloning everything, but 
> sometimes I'd like to say "I'm going to track the upstreams branch xyzzy 
> rather than their default branch").
> 
> I realize that the
> 
> 	git clone <repo> [<dir>]
> 
> means that we can't have the same syntax as "git pull" (which doesn't take 
> the <dir> part), but that doesn't make the "#branch" syntax any better.
> 
> So I much prefer the
> 
> 	git clone [--default branch] [--branch x]* <repo> [<dir>
> 
> kind of syntax.

Two questions:
- I understand --branch is too large for 1.5.0, but maybe this --default isn't?
- Or, maybe we can have a flag to avoid creating the master branch at all?
  User can combine this with -n, then check which branches exist with "git branch -r"
  and create the branch himself.

-- 
MST

Re: [PATCH] add --remote option to git-clone.

[Shawn O. Pearce]

Linus Torvalds <torvalds@linux-foundation.org> wrote:
> I realize that the
> 
> 	git clone <repo> [<dir>]
> 
> means that we can't have the same syntax as "git pull" (which doesn't take 
> the <dir> part), but that doesn't make the "#branch" syntax any better.
> 
> So I much prefer the
> 
> 	git clone [--default branch] [--branch x]* <repo> [<dir>]
> 
> kind of syntax.

Ugh.  That means the bash completion cannot (easily) do something
fancy, like tab completion of branch names within <repo>.  Yea,
its not fast on slow links, but it beats typing out an ugly branch
name.  :-)

-- 
Shawn.