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

Petr Baudis [off-list ref] writes:

quoted

I think you could run git-peek-remote to find all the refs and
then run git-fetch-pack to slurp all the tags (and heads for
that matter) at once.  Is there a particular reason you would
prefer the commit walker?

Actually, probably not, except consistency with rsync and http handling
- but that's obviously not too good reason.

We would end up doing things internally differently between
git-native (fetch/clone-pack) and other protocols (commit walker
which is git-aware, and rsync which is not) anyway.

I misspoke for 'git-fetch-pack' in the above -- git-fetch-pack
without any refspec fetches all the refs, so you do not need a
separate peek-remote.  Right now 'git fetch' wrapper does not
let you take advantage of this, but if we wanted to add '--all'
flag to 'git fetch' wrapper, it can be implemented very easily
and efficiently for the git-native protocol.  An implementation
of such a flag for other protocols would use git-ls-remote to
find out the refs upfront.

I will probably rewrite the tags fetching to use git-peek-remote
(info/refs for http) the next weekend.

If you are targetting multiple protocols, git-ls-remote is the
one to use, not peek-remote.  It internally uses peek-remote for
git-native protocol, and emulates it using info/refs for http
and recursive get for rsync, so no new coding on Cogito part
should be necessary.

default post-update hook could change to

	[ -e "$_git/git-dummy-support" ] && exec git-update-server-info

and be enabled by default?

That is a thought.  While I think doing update-server-info
everywhere whenever you update ref is going a bit overboard, I
agree there should be an easy way for the end user to keep
repositories that are public accessible all times.  But running
server-info upon every commit does not make much sense to me --
something is seriously broken if we need to do that.

Cases when you would want to make your repository accessible
from outside itself varies and preferred transport obviously
depends on it.

 - Your private working area.  Typically does not allow
   anonymous downloads.  You are the only one to use git tools
   and compilation there (that's what 'private' means).

 - A CVS style shared repository.  May allow anonymous
   downloads, and allow uploads to people with 'commit
   privilege' in CVS lingo.

 - A public distribution point, like kernel.org repository.
   This is just a special case of the 'shared repository' above,
   with yourself as the only uploader.

I thought there would be more classes, but it really boils down
to whether you would allow anonymous downloads or not -- so
let's call them private and public.

Fetching over non git-native protocol is the only case where
server-info matters; so obviously it is nicer if public
repository is arranged so that update-server-info is run
everytime refs and set of packs change.

I do not think of a good reason not to use git-aware protocol
when one is fetching from a private repo -- so if we just say
people should not use non git-aware protocol when doing so, we
do not have to do server-info in the private repositories at
all.

So the question is, how often do we need to run update to keep
the refs and set of packs in public repository in sync with the
server-info.  What do people do in public repository to affect
set of packs and the refs?

 - Initiate a push into it from somewhere else; this case is
   covered by enabling post-update hook.

 - You log on to the machine of public repository and run 'git
   repack'; this runs update-server-info, so it is OK.

 - You log on to the machine of public repository and run fetch
   of another repository -- you may even end up hand merging and
   creating new commits.

 - You log on to the machine of public repository and do your
   development, making your own commits.

It is the latter two cases where your 'update-server-info
everywhere in Cogito' would be needed -- but is it realistic?