threads / patch / 6615

patchadd --remote option to git-clone.

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

## tl;dr

20 messages between Feb 1, 2007 and Feb 5, 2007. Diffs are folded; open one to read it.

replies: 19people: 8as markdown or json

Michael S. Tsirkin· Feb 1, 2007, 22:01 UTC · lore

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.

Show changes to 2 files +57 −30

Documentation/git-clone.txt, git-clone.sh

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
J. Bruce Fields· Feb 1, 2007, 22:06 UTC · re: Michael S. Tsirkin · lore

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.

--b.
Shawn O. Pearce· Feb 1, 2007, 22:14 UTC · re: J. Bruce Fields · lore

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

"J. Bruce Fields" <bfields@fieldses.org> wrote:
Show 11 quoted lines
> 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.
Michael S. Tsirkin· Feb 1, 2007, 23:01 UTC · re: J. Bruce Fields · lore

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

Show 14 quoted lines
> 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
Yann Dirson· Feb 1, 2007, 23:42 UTC · re: J. Bruce Fields · lore

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

On Thu, Feb 01, 2007 at 05:06:57PM -0500, J. Bruce Fields wrote:
Show 11 quoted lines
> 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.
Shawn O. Pearce· Feb 1, 2007, 23:31 UTC · re: Johannes Schindelin · lore

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

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.
Michael S. Tsirkin· Feb 1, 2007, 23:47 UTC · re: Johannes Schindelin · lore

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

Show 6 quoted lines
> 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
Johannes Schindelin· Feb 1, 2007, 23:53 UTC · re: Michael S. Tsirkin · lore

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

Hi,
On Fri, 2 Feb 2007, Michael S. Tsirkin wrote:
Show 9 quoted lines
> > 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

Junio C Hamano· Feb 2, 2007, 01:25 UTC · re: Johannes Schindelin · lore

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

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
Show 7 quoted lines
> 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.
Johannes Schindelin· Feb 2, 2007, 10:48 UTC · re: Junio C Hamano · lore

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

Hi,
On Thu, 1 Feb 2007, Junio C Hamano wrote:
Show 19 quoted lines
> 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

Junio C Hamano· Feb 3, 2007, 03:00 UTC · re: Johannes Schindelin · lore

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

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
Show 10 quoted lines
> 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.

Jakub Narebski· Feb 3, 2007, 09:06 UTC · re: Junio C Hamano · lore

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

Junio C Hamano wrote:
Show 18 quoted lines
> 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
Junio C Hamano· Feb 3, 2007, 09:27 UTC · re: Jakub Narebski · lore

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

Jakub Narebski <jnareb@gmail.com> writes:
Show 9 quoted lines
>> 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.

Johannes Schindelin· Feb 5, 2007, 11:51 UTC · re: Junio C Hamano · lore

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

Hi,
On Fri, 2 Feb 2007, Junio C Hamano wrote:
Show 17 quoted lines
> 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".
Show 16 quoted lines
> 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.
Show 13 quoted lines
> 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

Junio C Hamano· Feb 5, 2007, 17:58 UTC · re: Johannes Schindelin · lore

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

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
Show 11 quoted lines
> 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.

Show 10 quoted lines
>> 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.

Linus Torvalds· Feb 5, 2007, 18:43 UTC · re: Junio C Hamano · lore

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

On Mon, 5 Feb 2007, Junio C Hamano wrote:
Show 8 quoted lines
> 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
Michael S. Tsirkin· Feb 5, 2007, 18:55 UTC · re: Linus Torvalds · lore

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

Show 18 quoted lines
> (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
Shawn O. Pearce· Feb 5, 2007, 19:34 UTC · re: Linus Torvalds · lore

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

Linus Torvalds <torvalds@linux-foundation.org> wrote:
Show 12 quoted lines
> 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.
Michael S. Tsirkin· Feb 5, 2007, 18:48 UTC · re: Junio C Hamano · lore

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

Show 8 quoted lines
> 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

← back to recent threads