Re: Question regarding git fetch

From: Avery Pennarun <apenwarr@gmail.com>
Date: Aug 27, 2009, 17:22 UTC
Message-ID: <32541b130908271022i6a825198i37e2ec82ed5f833c@mail.gmail.com>
In-Reply-To: <20090827164657.GA17090@atjola.homenet>

2009/8/27 Björn Steinbrink <B.Steinbrink@gmx.de>:

Show 6 quoted lines

> 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