[PATCH] Use new .git/config for storing "origin" shortcut repository

[PATCH] Use new .git/config for storing "origin" shortcut repository

[Andy Parkins]

If .git/remotes/ is now deprecated, then git-clone shouldn't use it.
This patch adds the analogous definitions to .git/config using
git-repo-config calls.

For example what was previously .git/remotes/origin
  URL: proto://host/path
  Pull: refs/heads/master:refs/heads/origin
Is now added to .git/config as
  [remote "origin"]
  url = proto://host/path
  fetch = refs/heads/master:refs/heads/origin

Signed-off-by: Andy Parkins <andyparkins@gmail.com>
---
I'm not sure if I'm correct in thinking that .git/remotes is deprecated.  If it is,
this patch makes git-clone use .git/config instead.

Personally I like it, I think there should be as small a number of places for 
configuring the repository as possible.


 git-clone.sh |    9 ++++-----
 1 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/git-clone.sh b/git-clone.sh
index 9ed4135..1057a26 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -373,9 +373,8 @@ then
 		*)	origin_track="$remote_top/$origin"
 			git-update-ref "refs/heads/$origin" "$head_sha1" ;;
 		esac &&
-		echo >"$GIT_DIR/remotes/$origin" \
-		"URL: $repo
-Pull: refs/heads/$head_points_at:$origin_track" &&
+		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
@@ -389,8 +388,8 @@ Pull: refs/heads/$head_points_at:$origin_track" &&
 			then
 				continue
 			fi
-			echo "Pull: refs/heads/${name}:$remote_top/${name}"
-		done >>"$GIT_DIR/remotes/$origin" &&
+			git-repo-config remote."$origin".fetch "refs/heads/${name}:$remote_top/${name}"
+		done &&
 		case "$use_separate_remote" in
 		t)
 			rm -f "refs/remotes/$origin/HEAD"
-- 
1.4.4.1.gb38c-dirty

Re: [PATCH] Use new .git/config for storing "origin" shortcut repository

[Johannes Schindelin]

Hi,

On Sun, 26 Nov 2006, Andy Parkins wrote:

> -			echo "Pull: refs/heads/${name}:$remote_top/${name}"
> -		done >>"$GIT_DIR/remotes/$origin" &&
> +			git-repo-config remote."$origin".fetch "refs/heads/${name}:$remote_top/${name}"
> +		done &&

This hunk is wrong: "git-repo-config remote.bla.fetch b" will _overwrite_ 
remoter.bla.fetch. To avoid that, you have to use "git repo-config 
remote.bla.fetch b ^$". (The last argument is a regular expression which 
has to be matched by the value-to-be-oreplaced.)

Ciao,
Dscho

Re: [PATCH] Use new .git/config for storing "origin" shortcut repository

[Shawn Pearce]

Andy Parkins <andyparkins@gmail.com> wrote:
> If .git/remotes/ is now deprecated, then git-clone shouldn't use it.
> This patch adds the analogous definitions to .git/config using
> git-repo-config calls.
> 
> For example what was previously .git/remotes/origin
>   URL: proto://host/path
>   Pull: refs/heads/master:refs/heads/origin
> Is now added to .git/config as
>   [remote "origin"]
>   url = proto://host/path
>   fetch = refs/heads/master:refs/heads/origin
> 
> Signed-off-by: Andy Parkins <andyparkins@gmail.com>
> ---
> I'm not sure if I'm correct in thinking that .git/remotes is deprecated.  If it is,
> this patch makes git-clone use .git/config instead.
> 
> Personally I like it, I think there should be as small a number of places for 
> configuring the repository as possible.

I agree.  There's all sorts of advantages to setting up remotes by
the config file.  Its also easier to load and work with in git-gui.
:-)

I've switched to the config file syntax completely, and a few folks
I work with have done the same, citing that it is easier to have
everything in one file.

-- 

Re: [PATCH] Use new .git/config for storing "origin" shortcut repository

[Junio C Hamano]

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

> This hunk is wrong: "git-repo-config remote.bla.fetch b" will _overwrite_ 
> remoter.bla.fetch. To avoid that, you have to use "git repo-config 
> remote.bla.fetch b ^$". (The last argument is a regular expression which 
> has to be matched by the value-to-be-oreplaced.)

Yup, one of the joys of working the config file everybody seems
to like ;-).

Re: [PATCH] Use new .git/config for storing "origin" shortcut repository

[Andy Parkins]

On Sunday 2006, November 26 00:48, Johannes Schindelin wrote:

> This hunk is wrong: "git-repo-config remote.bla.fetch b" will _overwrite_
> remoter.bla.fetch. To avoid that, you have to use "git repo-config
> remote.bla.fetch b ^$". (The last argument is a regular expression which
> has to be matched by the value-to-be-oreplaced.)

This is in git-clone; the config is empty.  What is there to overwrite?

I'll fix it anyway.


Andy

-- 
Dr Andrew Parkins, M Eng (Hons), AMIEE

Re: [PATCH] Use new .git/config for storing "origin" shortcut repository

[Junio C Hamano]

Andy Parkins <andyparkins@gmail.com> writes:

> On Sunday 2006, November 26 00:48, Johannes Schindelin wrote:
>
>> This hunk is wrong: "git-repo-config remote.bla.fetch b" will _overwrite_
>> remoter.bla.fetch. To avoid that, you have to use "git repo-config
>> remote.bla.fetch b ^$". (The last argument is a regular expression which
>> has to be matched by the value-to-be-oreplaced.)
>
> This is in git-clone; the config is empty.  What is there to overwrite?

The entry you wrote in the previous iteration in the same loop,
perhaps?

[PATCH] Use new .git/config for storing "origin" shortcut repository

[Andy Parkins]

Rather than use a separate config .git/remotes/ for remote shortcuts, this
patch adds the analogous definitions to .git/config using git-repo-config
calls.

For example what was previously .git/remotes/origin
  URL: proto://host/path
  Pull: refs/heads/master:refs/heads/origin
Is now added to .git/config as
  [remote "origin"]
  url = proto://host/path
  fetch = refs/heads/master:refs/heads/origin

Signed-off-by: Andy Parkins <andyparkins@gmail.com>
---
Oops; you're absolutely right.  I'd not realised that it was the add operation
that needed the special syntax rather than the replace.

 git-clone.sh |    9 ++++-----
 1 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/git-clone.sh b/git-clone.sh
index 9ed4135..19a5a63 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -373,9 +373,8 @@ then
 		*)	origin_track="$remote_top/$origin"
 			git-update-ref "refs/heads/$origin" "$head_sha1" ;;
 		esac &&
-		echo >"$GIT_DIR/remotes/$origin" \
-		"URL: $repo
-Pull: refs/heads/$head_points_at:$origin_track" &&
+		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
@@ -389,8 +388,8 @@ Pull: refs/heads/$head_points_at:$origin_track" &&
 			then
 				continue
 			fi
-			echo "Pull: refs/heads/${name}:$remote_top/${name}"
-		done >>"$GIT_DIR/remotes/$origin" &&
+			git-repo-config remote."$origin".fetch "refs/heads/${name}:$remote_top/${name} ^$"
+		done &&
 		case "$use_separate_remote" in
 		t)
 			rm -f "refs/remotes/$origin/HEAD"
-- 
1.4.4.1.g9fd7

Re: [PATCH] Use new .git/config for storing "origin" shortcut repository

[Jakub Narebski]

Andy Parkins wrote:

> +               git-repo-config remote."$origin".url "$repo" ^$ &&

Is this needed? As of now git supports I think only one URL entry per remote
anyway...
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

[PATCH] Use new .git/config for storing "origin" shortcut repository

[Andy Parkins]

Rather than use a separate config .git/remotes/ for remote shortcuts, this
patch adds the analagous definitions to .git/config using git-repo-config
calls.

For example what was previously .git/remotes/origin
  URL: proto://host/path
  Pull: refs/heads/master:refs/heads/origin
Is now added to .git/config as
  [remote "origin"]
  url = proto://host/path
  fetch = refs/heads/master:refs/heads/origin

Signed-off-by: Andy Parkins <andyparkins@gmail.com>
---
You're absolutely correct; fixed.  This patch replaces the previous (again).

 git-clone.sh |    9 ++++-----
 1 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/git-clone.sh b/git-clone.sh
index 9ed4135..7e5dc0f 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -373,9 +373,8 @@ then
 		*)	origin_track="$remote_top/$origin"
 			git-update-ref "refs/heads/$origin" "$head_sha1" ;;
 		esac &&
-		echo >"$GIT_DIR/remotes/$origin" \
-		"URL: $repo
-Pull: refs/heads/$head_points_at:$origin_track" &&
+		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
@@ -389,8 +388,8 @@ Pull: refs/heads/$head_points_at:$origin_track" &&
 			then
 				continue
 			fi
-			echo "Pull: refs/heads/${name}:$remote_top/${name}"
-		done >>"$GIT_DIR/remotes/$origin" &&
+			git-repo-config remote."$origin".fetch "refs/heads/${name}:$remote_top/${name}" ^$
+		done &&
 		case "$use_separate_remote" in
 		t)
 			rm -f "refs/remotes/$origin/HEAD"
-- 
1.4.4.1.g9fd7

Re: [PATCH] Use new .git/config for storing "origin" shortcut repository

[Johannes Schindelin]

Hi,

On Sun, 26 Nov 2006, Andy Parkins wrote:

> -		echo >"$GIT_DIR/remotes/$origin" \
> -		"URL: $repo
> -Pull: refs/heads/$head_points_at:$origin_track" &&
> +		git-repo-config remote."$origin".url "$repo" &&
> +		git-repo-config remote."$origin".fetch "refs/heads/$head_points_at:$origin_track" ^$ &&

You do not need the "^$" here: this _is_ the first entry. I would even 
argue that this _has_ to replace whatever might be there (could be 
introduced by some bogus templates, for example), since the first fetch 
entry has a special meaning for pull.

Ciao,
Dscho

Re: [PATCH] Use new .git/config for storing "origin" shortcut repository

[Johannes Schindelin]

Hi,

On Sat, 25 Nov 2006, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > This hunk is wrong: "git-repo-config remote.bla.fetch b" will _overwrite_ 
> > remoter.bla.fetch. To avoid that, you have to use "git repo-config 
> > remote.bla.fetch b ^$". (The last argument is a regular expression which 
> > has to be matched by the value-to-be-oreplaced.)
> 
> Yup, one of the joys of working the config file everybody seems to like 
> ;-).

The problem is: config files are ubiquitous, so you need not teach 
users about it. On the other hand, they are just key / value stores, i.e. 
reflecting a mapping. What we want here, is a multimapping, so we use the 
wrong tool.

But sometimes it is so much more pragmatic to just take off one shoe and 
put the darned nail back into the wall than to go to the shop, buy the 
hammer, go back, put the nail in, and try to sell the hammer via eBay.

BTW regarding your criticism of the config file: I agree that the write 
support of git-repo-config was quite brittle at the start. Which is my 
fault.

However, we had quite some flashing out bugs in the mean time, so I am 
quite confident in the tool. Of course, what with the recent addition of a 
user specific config file (which makes the name "repo-config" seem utterly 
wrong), there might be some dragons in the code.

So, it seems that the whole config writing code is a perfect opportunity 
for people wanting to audit source code!

Ciao,
Dscho