On Thu, Aug 27, 2009 at 05:22:55PM +0000, Avery Pennarun wrote: > 2009/8/27 Björn Steinbrink <B.Steinbrink@xxxxxx>: > > It would also be pretty hard to implement that. Given the default fetch > > refspec, it would "simply" be a matter of mapping the given ref to the > > refspec, so e.g. "foo" becomes "refs/heads/foo:refs/remotes/origin/foo". > > But even just using "git remote add -t master foo git://..." breaks > > that, as the fetch refspec in the config will no longer be a glob, and > > thus no such mapping is possible. > > Hmm, I don't really see why that introduces a problem. If you use -t > to override explicitly which refs you want to save, then it's not a > problem if git doesn't save other refs, right? I think you can handle both cases just by matching the fetched refs to the LHS of the refspec. So if you fetch "refs/heads/foo", and if you have a refspec of: refs/heads/*:refs/remotes/origin/* then you see that the LHS glob matches, and the RHS expands to refs/remotes/origin/foo. And if you have a more restrictive refspec, that would work, too: refs/heads/foo:refs/remotes/origin/foo would still match, but refs/heads/bar:refs/remotes/origin/bar does not match on the LHS, so you write nothing. It would even handle multiple refspecs properly. And this matching is not really any different than what the fetch code does when applying the refspec to what the remote offers. So I don't think it should be any significant new code; it's just a matter of activating that matching and updating the local tracking refs based on what we actually fetched, instead of what the remote advertised. > I'd be more concerned about the inconsistency between > > git fetch git://whatever master > and > git fetch origin master > > There's no really good way for the first one to know it needs to > update any branches, even though 'origin' might be an alias for > git://whatever. So users will still be confused. Well, you can always reverse-lookup each remote to see if the URL matches. Of course you would never know that "http://whatever"; is an alias for "git://whatever". Personally, I don't imagine that users really expect git to reverse-map remotes in that way (after all, why would they input git://whatever long-hand if they knew that it was a remote). > Thinking of that also reminds me of another surprise. If you do: > > git fetch git://whatever > > ...it seems to do nothing at all, as far as I can see. Which makes > sense, I guess, since I wouldn't really expect it to be meaningful. > But it seems to connect up to the remote server anyway just in case. Shouldn't it fetch HEAD from the remote and store it in FETCH_HEAD? And then tell you that it did that? I get: $ mkdir foo && cd foo && git init Initialized empty Git repository in /home/peff/foo/.git/ $ git fetch ~/compile/git remote: Counting objects: 85011, done. remote: Compressing objects: 100% (23942/23942), done. remote: Total 85011 (delta 61389), reused 83076 (delta 59655) Receiving objects: 100% (85011/85011), 19.03 MiB | 11385 KiB/s, done. Resolving deltas: 100% (61389/61389), done. From /home/peff/compile/git * branch HEAD -> FETCH_HEAD $ git fetch git://git.kernel.org/pub/scm/git/git.git From git://git.kernel.org/pub/scm/git/git * branch HEAD -> FETCH_HEAD -Peff -- 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