Junio C Hamano <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] (Eric W. Biederman) writes: > >> What we care about are the tag objects, those are the only kind >> that are verifiable and usable remotely. >> >> Now that I know we do not pull tags currently with any of the >> optimized transports, I would suggest taking the list of commit >> objects we are transporting and for each commit look in the >> remote repo/refs/tags and transferring every tag object we can find >> that refers to that commit. > > I do not think it is particularly a good idea to fetch a tag > that refers to a commit when the user asks only for that commit > (e.g. the user said "the head of this remote branch I am > tracking", and the head happened to have been tagged). Yes, it > may be convenient, but retrieving the commit chain and > retrieving tags are conceptually separate issues. A tag does > not necessarily refer to a commit, so your reverse index does > not make sense for a tag pointing at a blob, for example.
After thinking it through I have to agree but not for your reasons. The killer argument for me is that tags can be made at any time. Which means that any incremental scheme that links pulling of tags to the pulling of the objects they refer to will fail when the tag is made after you have pulled the object. So at the very least the computation of which tags to pull needs to be separate from the computation of which object to pull. > I think if we have discovery mechanism of remote tags/heads, we > do not need anything else. You _could_ say something like: > > $ git-list-remote --tags linux-2.6 > 9e734775f7c22d2f89943ad6c745571f1930105f v2.6.12-rc2 > 26791a8bcf0e6d33f43aef7682bdb555236d56de v2.6.12 > ... > a339981ec18d304f9efeb9ccf01b1f04302edf32 v2.6.13-rc3 > $ git-list-remote --tags linux-2.6 | > while read sha1 tag; > do > git fetch linux-2.6 tag $tag > done > > and you are done. We did not use the reverse index, nor we used > the --all-tags flag to git-fetch-script. You do not even need > git-list-remote if you are willing to wget a=summary output from > gitweb and parse the bottom of the page ;-). I agree that anything we do will need to look roughly like the above. Beyond a simple index of what tags are present in the objects directory I can't think of anything that would be a cost savings, except possibly ordering the tags by creation date. There are a couple pieces of your example that disturb me. - The tag names are forced to be the same between trees. - You don't verify the tags before installing them. - I view tags as history and by having tag fetching totally separate it becomes easy to loose that history. I do like the fact that when you fetch a tag you are certain to fetch all of the objects and it refers to. I don't know what the solution is but we seem to be getting closer. Eric - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
