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

Petr Baudis <pasky@suse.cz> writes:

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.

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.

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?