Re: [PATCH] push: fix local refs update if already up-to-date

[Clemens Buchacher <drizzd@aon.at>]

On Tue, Nov 04, 2008 at 12:38:37AM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
> 
> > Though I am not happy that we have to look up the tracking ref for every
> > uptodate ref. I think it shouldn't be a big performance problem with
> > packed refs, though, since they are cached (i.e., we pay only to compare
> > the hashes, not touch the filesystem for each ref).
> 
> It is either (1) the user pays the cost of finding what remote tracking
> branch we are mirroring when you push for all up-to-date refs, like you
> did in your "here is an improvement" patch; or (2) the user pays the cost
> of fetching from there, immediately after pushing.  I'd imagine that the
> cost to do (1) would be smaller than (2).  The question is if seeing stale
> tracking branches is such a big deal, as next "git fetch" from there will
> update them anyway.  If it is a big deal, (1) would be a price worth
> paying.

Right. I think it is a big deal. I found out about this bug, because a user
on #git was confused by the fact that push reported "Everything up-to-date",
even though there were changes. A fetch fixed that, of course. But it is
confusing and inconsistent with normal push behavior. So I really think it's
worth a small performance hit.

> Clemens, care to reroll the patch?

I will do so later today.