On Tue, Apr 22, 2008 at 12:55:03PM +0200, Mike Galbraith wrote: > > [remote "x86"] > > url = ... > > fetch = +refs/heads/*:refs/remotes/x86/* > > > > See 'git help fetch' for details. > > Thanks a bunch. I'll try it. I notice that origin and linux-next > already had + prefix. Presumably that came from the home repo. Cloning creates an origin with '+' in the fetch line, but "git remote add" doesn't seem to. Hrm, it looks like this is a regression from the recent rewrite in C. Dscho, is this a bug, or was there a conscious decision that I missed? If a bug, the fix is below. -- >8 -- remote: create fetch config lines with '+' Since git-remote always uses remote tracking branches, it should be safe to always force updates of those branches. I.e., we should generate fetch = +refs/heads/*:refs/remotes/$remote/* instead of fetch = refs/heads/*:refs/remotes/$remote/* This was the behavior of the perl version, which seems to have been lost in the C rewrite. Signed-off-by: Jeff King <peff@xxxxxxxx> --- builtin-remote.c | 1 + t/t5505-remote.sh | 10 ++++++++++ 2 files changed, 11 insertions(+), 0 deletions(-) diff --git a/builtin-remote.c b/builtin-remote.c index 9d4432b..8b63619 100644 --- a/builtin-remote.c +++ b/builtin-remote.c @@ -107,6 +107,7 @@ static int add(int argc, const char **argv) struct path_list_item *item = track.items + i; strbuf_reset(&buf2); + strbuf_addch(&buf2, '+'); if (mirror) strbuf_addf(&buf2, "refs/%s:refs/%s", item->path, item->path); diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh index af2d077..48ff2d4 100755 --- a/t/t5505-remote.sh +++ b/t/t5505-remote.sh @@ -77,6 +77,16 @@ test_expect_success 'add another remote' ' ) ' +test_expect_success 'remote forces tracking branches' ' +( + cd test && + case `git config remote.second.fetch` in + +*) true ;; + *) false ;; + esac +) +' + test_expect_success 'remove remote' ' ( cd test && -- 1.5.5.1.116.g0023.dirty -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html