Petr Baudis wrote: > Dear diary, on Sat, Sep 24, 2005 at 03:18:33AM CEST, I got a letter > where Petr Baudis <pasky@suse.cz> told me that... > >>Dear diary, on Sat, Sep 24, 2005 at 12:24:06AM CEST, I got a letter >>where "H. Peter Anvin" <hpa@zytor.com> told me that... >> >>>Packed tag objects breaks Cogito when using git+ssh:// transport. >>> >>>Example: >>> >>>cg-clone -s git+ssh://master.kernel.org/pub/scm/libs/klibc/klibc.git >> >>I changed the code to use the git-*-fetch tools to fetch the objects >>referenced by tags, so this works properly now. Thanks for the report. > > > And now thanks to "walt" I realized that this is a completely wrong way > to go. The problem is that the tags don't have to tag anything on your > branch, and if you are fetching a given branch, you want only commits > from that branch. But fetching the tags will cause all the commits > connected to the tags getting slurped too, and we didn't want that. > > So the strategy I'm thinking of now is to manually (I think no GIT tool > can do that for me) dereference the possible tag chain until I end up at > some non-tag object. Now, if it is a commit and I don't have it yet, it > means that it is not interesting to me because it does not belong to a > branch I'm following, so I will just ignore the tag (won't download > anything else and won't record it in the refs/tags directory). I think this is the right idea. > If it's NOT a commit, well, that's a question. On the assumption that > it won't be a great deal of data and it's likely to be assumed that we > have it, I would be inclined to fetching it, but I don't feel strongly > about it. It could point to a tree (ie. the kernel's v2.6.11 tag), which may end up being a large pull. I think it's best to not care what type of object the tag references. -- Brian Gerst - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.htmlReceived on Tue Sep 27 07:54:49 2005
This archive was generated by hypermail 2.1.8 : 2005-09-27 07:54:52 EST