Use new .git/config for storing "origin" shortcut repository
A message that is not in the archive (sent off-list or not yet received): [email protected]
PATCH 1/1 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
---
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(-)
git-clone.sh +4 -5
@@ -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"
Signature · 1 line
1.4.4.1.gb38c-dirty
Hi,
git-clone.sh Pull: refs/heads/$head_points_at:$origin_track" && · line 392
Quoted 4 lines · Andy Parkins
git-clone.sh +2
-2- 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
Quoted 4 lines · Johannes Schindelin
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
Signature · 1 line
Dr Andrew Parkins, M Eng (Hons), AMIEE
Quoted 8 lines · Andy Parkins
Quoted 4 lines · Johannes Schindelin
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 1/1 Use new .git/config for storing "origin" shortcut repository
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
---
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(-)
git-clone.sh +4 -5
@@ -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"
Signature · 1 line
1.4.4.1.g9fd7
Quoted 1 line · Andy Parkins
+ git-repo-config remote."$origin".url "$repo" ^$ &&
Is this needed? As of now git supports I think only one URL entry per remote anyway...
Signature · 3 lines
Jakub Narebski Warsaw, Poland ShadeHawk on #git
PATCH 1/1 Use new .git/config for storing "origin" shortcut repository
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
---
You're absolutely correct; fixed. This patch replaces the previous (again).
git-clone.sh | 9 ++++----- 1 files changed, 4 insertions(+), 5 deletions(-)
git-clone.sh +4 -5
@@ -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"
Signature · 1 line
1.4.4.1.g9fd7
Hi,
git-clone.sh then · line 377
Quoted 5 lines · Andy Parkins
git-clone.sh +2
-3- 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
Quoted 4 lines · Johannes Schindelin
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 ;-).
Hi,
Quoted 9 lines · Junio C Hamano
Quoted 4 lines · Johannes Schindelin
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
Quoted 12 lines · 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
Quoted 7 lines
Signed-off-by Andy Parkins <[email protected]>---
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.