git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH 3/3] git-fetch: allow glob pattern in refspec
@ 2006-11-23  7:24 Junio C Hamano
  2006-11-23  8:55 ` Andy Parkins
  2006-11-27 18:14 ` Michael Loeffler
  0 siblings, 2 replies; 3+ messages in thread
From: Junio C Hamano @ 2006-11-23  7:24 UTC (permalink / raw)
  To: git; +Cc: Andy Parkins

This adds Andy's refspec glob.  You can have a single line:

	Pull: refs/heads/*:refs/remotes/origin/*

in your ".git/remotes/origin" and say "git fetch" to retrieve
all refs under heads/ at the remote side to remotes/origin/ in
the local repository.

Signed-off-by: Junio C Hamano <junkio@cox.net>
---

 * Andy, I think this does the same thing as you wanted to do,
   but is cleaner implementation-wise and also at the concept
   level, to pretend as if the user listed the expanded form in
   the configuration.  I deliberately decided not to apply the
   wildcard expansion on refspecs that came from command line,
   but if we wanted to we can move the expand_refs_wildcard call
   a few lines down to make it also apply to them.

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

diff --git a/git-parse-remote.sh b/git-parse-remote.sh
index c325ef7..e281b7c 100755
--- a/git-parse-remote.sh
+++ b/git-parse-remote.sh
@@ -90,6 +90,39 @@ get_remote_default_refs_for_push () {
 	esac
 }
 
+# Called from canon_refs_list_for_fetch -d "$remote", which
+# is called from get_remote_default_refs_for_fetch to grok
+# refspecs that are retrieved from the configuration, but not
+# from get_remote_refs_for_fetch when it deals with refspecs
+# supplied on the command line.  $ls_remote_result has the list
+# of refs available at remote.
+expand_refs_wildcard () {
+	for ref
+	do
+		# a non glob pattern is given back as-is.
+		expr "z$ref" : 'zrefs/.*/\*:refs/.*/\*$' >/dev/null || {
+			echo "$ref"
+			continue
+		}
+		from=`expr "z$ref" : 'z\(refs/.*/\)\*:refs/.*/\*$'`
+		to=`expr "z$ref" : 'zrefs/.*/\*:\(refs/.*/\)\*$'`
+		echo "$ls_remote_result" |
+		(
+			IFS='	'
+			while read sha1 name
+			do
+				mapped=${name#"$from"}
+				if test "z$name" != "z${name#'^{}'}" ||
+					test "z$name" = "z$mapped"
+				then
+					continue
+				fi
+				echo "${name}:${to}${mapped}"
+			done
+		)
+	done
+}
+
 # Subroutine to canonicalize remote:local notation.
 canon_refs_list_for_fetch () {
 	# If called from get_remote_default_refs_for_fetch
@@ -107,6 +140,8 @@ canon_refs_list_for_fetch () {
 			merge_branches=$(git-repo-config \
 			    --get-all "branch.${curr_branch}.merge")
 		fi
+		set x $(expand_refs_wildcard "$@")
+		shift
 	fi
 	for ref
 	do
-- 
1.4.4.1.g77614


^ permalink raw reply related	[flat|nested] 3+ messages in thread

* Re: [PATCH 3/3] git-fetch: allow glob pattern in refspec
  2006-11-23  7:24 [PATCH 3/3] git-fetch: allow glob pattern in refspec Junio C Hamano
@ 2006-11-23  8:55 ` Andy Parkins
  2006-11-27 18:14 ` Michael Loeffler
  1 sibling, 0 replies; 3+ messages in thread
From: Andy Parkins @ 2006-11-23  8:55 UTC (permalink / raw)
  To: git

On Thursday 2006 November 23 07:24, Junio C Hamano wrote:

>  * Andy, I think this does the same thing as you wanted to do,
>    but is cleaner implementation-wise and also at the concept

It certainly is.  Looking at your implementation I see that I was worrying 
unnecessarily about passing extra globals/parameters to git-parse-remote.  
Your version is much better than mine; and I see that noone else calls 
get_remote_refs_for_fetch anyway.

>    level, to pretend as if the user listed the expanded form in
>    the configuration.  I deliberately decided not to apply the
>    wildcard expansion on refspecs that came from command line,
>    but if we wanted to we can move the expand_refs_wildcard call
>    a few lines down to make it also apply to them.

That's probably the most sensible method.  Using globs on the command line 
could get people into trouble if they accidentally hit a shell expansion.


Andy
-- 
Dr Andy Parkins, M Eng (hons), MIEE

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH 3/3] git-fetch: allow glob pattern in refspec
  2006-11-23  7:24 [PATCH 3/3] git-fetch: allow glob pattern in refspec Junio C Hamano
  2006-11-23  8:55 ` Andy Parkins
@ 2006-11-27 18:14 ` Michael Loeffler
  1 sibling, 0 replies; 3+ messages in thread
From: Michael Loeffler @ 2006-11-27 18:14 UTC (permalink / raw)
  To: git

hi,

Am Mittwoch, den 22.11.2006, 23:24 -0800 schrieb Junio C Hamano: 
> This adds Andy's refspec glob.  You can have a single line:
> 
> 	Pull: refs/heads/*:refs/remotes/origin/*
How about using extended regex for this, something like this:
Pull: refs/heads/master:refs/remotes/origin/master
Pull: refs/tags/v(.*):refs/tags/origin/v\1

... 
> +expand_refs_wildcard () {
> +	for ref
> +	do
...
How about using something like:
echo "$ls_remote_result" | sed -n -r -e "s:$ref: p"

Using $ref as a part of the sed expression is not a good idea (.* should
not match past the ':'), but something like this maybe. What do you
think?

bye

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2006-11-27 18:14 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-11-23  7:24 [PATCH 3/3] git-fetch: allow glob pattern in refspec Junio C Hamano
2006-11-23  8:55 ` Andy Parkins
2006-11-27 18:14 ` Michael Loeffler

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).