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

[Petr Baudis <pasky@suse.cz>]

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...
> 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...
> 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.