Re: Cogito: cg-clone doesn't like packed tag objects

From: Petr Baudis <pasky@suse.cz>
Date: Sep 27, 2005, 09:40 UTC
Message-ID: <20050927094029.GA30889@pasky.or.cz>
In-Reply-To: <7v3bnra20z.fsf@assigned-by-dhcp.cox.net>

Dear diary, on Tue, Sep 27, 2005 at 07:28:16AM CEST, I got a letter where Junio C Hamano <junkio@cox.net> told me that...

Show 16 quoted lines

> Tom Prince <tom.prince@ualberta.net> writes:
> 
> > Junio C Hamano <junkio@cox.net> writes:
> >
> >> Now you completely lost me.  I really do not understand what you
> >> mean by tags caching and re-slurping.
> >
> > I think Petr is interested in the case where the user hasn't asked for a
> > particular tag. He wants to automatically grab all the tags in a repository,
> > or at least those that refer to a branch being downloaded.
> 
> Ah, _automatically_ was the key.
> 
> If all you had were tags and there were no branches (the "I
> could have done without maint branch"), that kind of automatic
> grabbing would not work well anyway.

I don't think that's a realistic situation. IMHO it is a reasonable requirement for Cogito fetch that you are primarily fetching a _head_. Then, you also grab tags which are meaningful for that head - that's what I want to do. If you want to also specifically grab some extra tags, you should be able to tell cg-fetch about that too (cg-fetch -t tagname) or something. Being able to do this, I'm inclined to agree that we shouldn't grab even trees and blobs.

> I personally feel that is a lost cause.  The user can run 'git
> ls-remote' himself to find out if there are new tags on the remote
> side and ask for them if needed.

Yes, that's perhaps a fine solution for the core GIT plumbing, but in Cogito, I _really_ want to have this working automagically.

> Also, I feel names under refs/ is local to the repository, but
> if the tags are automatically grabbed, I presume they are stored
> directly under the same name in refs/tags as the remote side has
> them?

Yes. And I certainly don't say that what Cogito does now is perfect, not even that it's very good. But we (well, rather the users) certainly _do_ need some kind of automatic tags fetching - that's something that has to Just Work (tm).

As I already said in the past (without much feedback, unfortunately), we certainly need to distinguish between private tags (specific for given repository) and public tags (should be propagated by fetching).

Another thing I proposed back then (I think it was in June) was having the refs/tags directory further divised based on heads, so all tags for head A would be in refs/tags/A/, etc. I didn't pursue this idea now because it seemed that there would be way too many duplicate stuff in refs/tags/ since most tags are likely to be shared across heads, but perhaps it is the beast and cleanest solution after all.

Dear diary, on Tue, Sep 27, 2005 at 12:37:48AM CEST, I got a letter where Junio C Hamano <junkio@cox.net> told me that...

Show 8 quoted lines

> I think there should be a way to say "I do not care if this
> repository does not have all the history back to root -- as long
> as I can operate on reasonably recent commits, do not complain
> about missing objects" to fsck-objects and various fetch
> engines.  We can cauterize commit history chain using the grafts
> file so that 'git log', 'git whatchanged', and 'gitk' would stop
> somewhere.  Commit walkers can help you, albeit somewhat
> differently, if you do not give -a flag to them.

Well, this wasn't something I had on my mind in this thread, but it is actually what I want to do too (I have such a loooong TODO list). Sure, you can workaround the problem with grafts, but I think that this hack should be really used only in specific cases (like grafting big history pack after importing the project to GIT, making it kind of optional "addon", which is actually very nice). In the general case, I would much more like if you could say "I want only commits to the depth of 5" or even CVS-like "I want only the HEAD commit" (actually, I received some patches to make Cogito support this, but I didn't yet get to have a look at them). This shifts the policy decision from the repository owner to the user, and makes it contignuous instead of fragmented to the points when you have grafts.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.