Re: [PATCH] push: fix local refs update if already up-to-date
- From
Clemens Buchacher <drizzd@aon.at>
- Date
- Nov 4, 2008, 09:05 UTC
- Message-ID
- <20081104090519.GB22530@localhost>
- In-Reply-To
- <7v7i7jsx6a.fsf@gitster.siamese.dyndns.org>
On Tue, Nov 04, 2008 at 12:38:37AM -0800, Junio C Hamano wrote:
Show 15 quoted lines
> 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.