Junio C Hamano <gitster@xxxxxxxxx> wrote: > "Shawn O. Pearce" <spearce@xxxxxxxxxxx> writes: > > > We now redefine the rule to be: "tags are fetched if they refer > > to an object that was just transferred; that is an object that is > > new to your repository". This rule is quite simple to understand, > > you only get a tag if you just got the object it refers to. > > In other words, if I do this: > > git fetch git-gui master > > (which should not follow any tags) when your master is a bit > ahead of a new tag in git-gui I do not have, and then > immediately afterwards if I do: > > git fetch git-gui > > I will not get the new tag followed? > > If that is what the patch does, it feels like a regression. Yeah, that's what it does, and everyone has stated its a regression so its not the right change to make here. > The intended behaviour was "when tag following is enabled, they > are followed if they refer to an object that is reachable from > your existing refs". > > But this is quite expensive to compute. If a tag points at a > blob that is contained inside a commit that is reachable from a > ref, we would need to grep "git rev-list --objects -all" output > to find it out. I do not offhand recall what the scripted > version did, but I would not be surprised if as an approximation > we did the auto-following by "does the pointee exist" check. We just did `git cat-file -t`. If it passed then we followed the tag. Which means we could just do a has_sha1_file() test and call it a day. If the object is already reachable from our current refs we'll only download the tag; if it isn't really reachable but is dangling in the ODB we'll download possibly a lot of objects. I was trying to make tag auto-following only work if the tag's target was already completely available and we'd only need to download the tag object itself. > What "random behaviour" are you trying to fix? Apparently I'm introducing even more random behavior. It may have just been a bug in the past. Or a tag whose referred object wasn't reachable from a ref but I thought it should have been. Obviously my patch series resolves neither. -- Shawn. - 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
