threads / patch / 43085

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

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

## tl;dr

6 messages between Nov 26, 2006 and Nov 26, 2006. Diffs are folded; open one to read it.

replies: 5people: 4as markdown or json

Andy Parkins· Nov 26, 2006, 00:03 UTC · lore

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

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(-)

Show changes to git-clone.sh +4 −5

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

Johannes Schindelin· Nov 26, 2006, 00:48 UTC · re: Andy Parkins · lore

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

Junio C Hamano· Nov 26, 2006, 03:52 UTC · re: Johannes Schindelin · lore

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 ;-).

Johannes Schindelin· Nov 26, 2006, 13:45 UTC · re: Junio C Hamano · lore

Hi,

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

Show 9 quoted lines

> 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

Andy Parkins· Nov 26, 2006, 08:56 UTC · re: Johannes Schindelin · lore

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

Shawn Pearce· Nov 26, 2006, 03:02 UTC · re: Andy Parkins · lore

Andy Parkins <andyparkins@gmail.com> wrote:

Show 19 quoted lines

> 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.