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'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. 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. I suppose I have no useful suggestions here, other than an interpretation of why users find the current behaviour confusing. Have fun, Avery -- 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