On Tue, Nov 04, 2008 at 12:38:37AM -0800, Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
