Re: Question regarding git fetch

From: Jeff King <peff@peff.net>
Date: Aug 27, 2009, 20:48 UTC
Message-ID: <20090827204835.GC4399@coredump.intra.peff.net>
In-Reply-To: <32541b130908271022i6a825198i37e2ec82ed5f833c@mail.gmail.com>

On Thu, Aug 27, 2009 at 05:22:55PM +0000, Avery Pennarun wrote:

Show 11 quoted lines

> 2009/8/27 Björn Steinbrink <B.Steinbrink@gmx.de>:
> > 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.

Show 9 quoted lines

> 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).

Show 7 quoted lines

> 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