Re: history missing

[Jeff King <peff@peff.net>]

On Mon, Nov 08, 2010 at 09:14:27AM -0500, Martin von Zweigbergk wrote:

> On Mon, Nov 8, 2010 at 8:48 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> > On Mon, 8 Nov 2010, Martin von Zweigbergk wrote:
> >> Sorry, maybe I misunderstood what the confusion was about. What I was
> >> referring to was the confusion caused by 'git fetch origin master' not
> >> updating 'refs/remotes/origin/master'.
> >
> > Should it really do it?  What if it does not exist?  What if <remote>
> > is specified via URL?
> 
> I would probably not expect it to be updated (even if the URL matches a
> configured remove). If the reference does not yet exist, I think I would
> expect it to be created.

Yeah, the patch I posted a while back (and referenced below) does not
convert URLs into remote names (nor do I think it should). But if you
give it the name of a configured remote, and it is fetching a ref from
the remote that is mentioned on the LHS of a configured fetch refspec,
it will update the matching RHS of that refspec opportunistically.

So it should be pretty unsurprising to the user (see the thread below
for some discussion of when it could be surprising).

> Also see http://thread.gmane.org/gmane.comp.version-control.git/127163/.
> Junio, Jeff and Avery can argue much better for and against this than I
> can. I read it at some point, but I don't quite remember now if they did
> discuss the historical reasons for the current behavior in that thread.

I took a look at cleaning up the patch from that thread. It causes 4 of
the test scripts to fail. Most disturbing is this one:

  $ grep explicit.fetch t/t5510-fetch.sh
  test_expect_success 'explicit fetch should not update tracking' '

which checks for the direct opposite of the behavior we are discussing.
The test was added by Junio in late 2007. However, I can't seem to find
any discussion on the mailing list about it. Junio, do you remember
anything about this?

-Peff