[PATCH] git-clone: use wildcard specification for tracking branches

This stops enumerating the set of branches found on the remote
side when a clone was made in the configuration file.  Instead,
a single entry that maps each remote branch to the local
tracking branch for the remote under the same name is created.

Doing it this way not only shortens the configuration file, but
automatically adjusts to a new branch added on the remote side
after the clone is made.

Unfortunately this cannot be done for the traditional layout,
where we always need to special case the 'master' to 'origin'
mapping within the local branch namespace.  But that is Ok; it
will be going away before v1.5.0.

We could also lose the "primary branch" mapping at the
beginning, but that has to wait until we implement the "forbid
'git pull' when we do not have branch.$current.merge for the
current branch" policy we earlier discussed.  That should also
be in v1.5.0

Signed-off-by: Junio C Hamano <redacted>

---
Junio C Hamano [off-list ref] writes:

Things that need to be done to complete what have been merged to
'master' are:
...
 - 'git-clone' probably should be updated to use wild-card in
   remote.origin.fetch, instead of listing all the branches it
   found when the clone was made.

 git-clone.sh |   47 ++++++++++++++++++++++++++++++-----------------
 1 files changed, 30 insertions(+), 17 deletions(-)

diff --git a/git-clone.sh b/git-clone.sh
index 1f5d07a..422499a 100755
--- a/git-clone.sh
+++ b/git-clone.sh

@@ -366,41 +366,54 @@ then
 		)
 	)
 
-	# Write out remotes/$origin file, and update our "$head_points_at".
+	# Write out remote.$origin config, and update our "$head_points_at".
 	case "$head_points_at" in
 	?*)
-		mkdir -p "$GIT_DIR/remotes" &&
+		# Local default branch
 		git-symbolic-ref HEAD "refs/heads/$head_points_at" &&
+
+		# Tracking branch for the primary branch at the remote.
 		case "$use_separate_remote" in
 		t)	origin_track="$remote_top/$head_points_at"
 			git-update-ref HEAD "$head_sha1" ;;
 		*)	origin_track="$remote_top/$origin"
 			git-update-ref "refs/heads/$origin" "$head_sha1" ;;
 		esac &&
+
+		# Upstream URL and the primary branch tracking
 		git-repo-config remote."$origin".url "$repo" &&
 		git-repo-config remote."$origin".fetch \
 			"refs/heads/$head_points_at:$origin_track" &&
-		(cd "$GIT_DIR/$remote_top" && find . -type f -print) |
-		while read dotslref
-		do
-			name=`expr "$dotslref" : './\(.*\)'`
-			if test "z$head_points_at" = "z$name"
-			then
-				continue
-			fi
-			if test "$use_separate_remote" = '' &&
-			   test "z$origin" = "z$name"
-			then
-				continue
-			fi
-			git-repo-config remote."$origin".fetch "refs/heads/${name}:$remote_top/${name}" '^$'
-		done &&
+
+		# Set up the mappings to track the remaining branches.
+		case "$use_separate_remote" in
+		t)
+			git-repo-config remote."$origin".fetch \
+				"refs/heads/*:$remote_top/*" '^$'
+			;;
+		*)
+			(cd "$GIT_DIR/$remote_top" && find . -type f -print) |
+			while read dotslref
+			do
+				name=`expr "$dotslref" : './\(.*\)'`
+				if test "z$head_points_at" = "z$name" ||
+					test "z$origin" = "z$name"
+				then
+					continue
+				fi
+				git-repo-config remote."$origin".fetch \
+				"refs/heads/${name}:$remote_top/${name}" '^$'
+			done
+			;;
+		esac &&
+
 		case "$use_separate_remote" in
 		t)
 			rm -f "refs/remotes/$origin/HEAD"
 			git-symbolic-ref "refs/remotes/$origin/HEAD" \
 				"refs/remotes/$origin/$head_points_at"
 		esac &&
+
 		git-repo-config branch."$head_points_at".remote "$origin" &&
 		git-repo-config branch."$head_points_at".merge "refs/heads/$head_points_at"
 	esac

On Sat, 16 Dec 2006, Junio C Hamano wrote:

Everybody hated the pull behaviour of merging the first branch
listed on remotes/* file (or remote.*.fetch config) into the
current branch.  This finally corrects that UI wart by
forbidding "git pull" without an explicit branch name on the
command line or branch.$current.merge for the current branch.

Yay!

May I suggest also just merging the built-in 3-way merge, and just calling 
the resulting version 1.5.0?

With all the "git add" and documentation cleanups, and these kinds of 
fundamental changes in behaviour (not that anybody will hopefully 
_notice_, and if they do they'll hopefully just be grateful, but it's 
still conceptually a big step), I think it's definitely worth a new 
version number.

Maybe even "2.0", although since we're still backwards compatible in all 
ways that really matter, a major number might be too big a step.

Everybody hated the pull behaviour of merging the first branch
listed on remotes/* file (or remote.*.fetch config) into the
current branch.  This finally corrects that UI wart by
forbidding "git pull" without an explicit branch name on the
command line or branch.$current.merge for the current branch.

The matching change to git-clone was made to prepare the default
branch.*.merge entry for the primary branch some time ago.

Signed-off-by: Junio C Hamano <redacted>

---
Junio C Hamano [off-list ref] writes:

We could also lose the "primary branch" mapping at the
beginning, but that has to wait until we implement the "forbid
'git pull' when we do not have branch.$current.merge for the
current branch" policy we earlier discussed.  That should also
be in v1.5.0

  And this does exactly that.

 git-parse-remote.sh |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/git-parse-remote.sh b/git-parse-remote.sh
index 6ae534b..7cd79c2 100755
--- a/git-parse-remote.sh
+++ b/git-parse-remote.sh

@@ -144,7 +144,8 @@ canon_refs_list_for_fetch () {
 			curr_branch=$(git-symbolic-ref HEAD | \
 			    sed -e 's|^refs/heads/||')
 			merge_branches=$(git-repo-config \
-			    --get-all "branch.${curr_branch}.merge")
+			    --get-all "branch.${curr_branch}.merge") ||
+			merge_branches=.this.would.never.match.any.ref.
 		fi
 		set x $(expand_refs_wildcard "$@")
 		shift

Junio C Hamano wrote:

This stops enumerating the set of branches found on the remote
side when a clone was made in the configuration file.  Instead,
a single entry that maps each remote branch to the local
tracking branch for the remote under the same name is created.

Doing it this way not only shortens the configuration file, but
automatically adjusts to a new branch added on the remote side
after the clone is made.

[...]

Does this deal with non-fast-forward branches like 'pu'? Does
it add $head_points_at at the beginning, before glob... wait,
this is not needed if there is branch.$head_points_at.merge.
But perhaps it still would be better to have:

  [remote "origin"]
        url   = git://git.kernel.org/pub/scm/git/git.git
        fetch = refs/heads/master:refs/remotes/origin/master
        fetch = refs/heads/*:refs/remotes/origin/*
        fetch =+refs/heads/pu:refs/remotes/origin/pu

  [branch "master"]
        remote = origin
        merge  = refs/heads/master ;# full spec of remote branch

But this is very nice. Thanks.
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git