some questions

Hello,

I try to migrate our old cvs repo to git. However, I still have to following questions that I found difficult to answer with the documentation.

- Is there a way to convert a indexVersion 1
  repo to indexVersion 2? (And vice versa?)

- Is there a way to find out if a repository
  is indexVersion 1 or indexVersion 2 (from
  the pack/index files)?

- http for git seems to be read-only/fetch.
  Would it be (theoretically) possible to
  support write/push (with WebDAV or so)?

- I do not fully understand the implication
  of 'git repack -a' (or 'git repack -A -d').
  Is this bad for remote repos that are used
  with http? (as '-a' is 'Especially useful when
  packing a repository that is used for private
  development and there is no need to worry about
  people fetching via dumb protocols from it').

- What would be the implication to mount the
  git repo with nts (or another remote fs).
  Is it save to use such a mounted repo from
  more than one computer?

Kind regards,

Thomas

Thomas Pasch <thomas.pasch@jentro.com> writes:

The index itself is just a little file in .git/index. There might be a better solution, but just

  rm .git/index
  git reset

seems to do it (of course, don't do while you have staged changes in the index !).

http://www.kernel.org/pub/software/scm/git/docs/howto/setup-git-server-over-http.txt

(BTW, that's the first result in http://www.google.com/search?q=git+webdav ;-) )

Matthieu Moy <Matthieu.Moy@imag.fr> wrote:

True, that would reset the dircache (aka .git/index). But we only have effectively 1 version of the dircache. Sure there was an older version, way back before it got a version header and the ability to get extension sections added. I don't think there are many clients using that format anymore. That format predates the 1.4 series, and we really encourage people to be on 1.5 or later.

The original poster asked about indexVersion 1 and indexVersion 2,
which means he is probably talking about pack.indexVersion and thus
a .idx file alongside a pack, not the dircache file that tracks
the working tree state.
 

Thomas Pasch <thomas.pasch@jentro.com> writes:

I think the only solution is to simply remove index,
ensure configuration (pack.indexVersion), and recreate
it using git-index-pack(1).
 

There is some magic number used to distinguish between pack index version 1 and version 2.

See Documentation/technical/pack-format.txt for details.

It *is* supported (via https).

There was even attempt to create 'smart' http push via web server module or CGI script, but IIRC it hit feature freeze and discussion petered out, so only parts of it are in 'pu'.

Search for "Add Git-aware CGI for Git-aware smart HTTP transport", "More on git over HTTP POST"

  http://thread.gmane.org/gmane.comp.version-control.git/91104
 

Dumb protocols currently _always_ download whole packfiles, so if you want to serve dumb protocols you might want to offer (also?) smaller packfiles. You can, for example, use .keep files and 'git repack -a' wouldn't matter.

You can try to search archives for "generational packing" or something like that...

Should work without problems, _unless_ you mean that you want to use multiple working directories with single repository. Then there are a couple of thing that you have to be beware of (but you can instead use alternates mechanism).

Jakub Narebski <jnareb@gmail.com> wrote:

Just change pack.indexVersion in .git/config to have the version you want and run `git gc` to repack the repository. If you created this repository by cloning another you may need to first delete any .keep files:

	rm -f .git/objects/pack/*.keep
  

  for i in .git/objects/pack/pack-*.idx; do
  dd if=$i bs=12 count=1 | od -c
  done

A line like:

0000000   �   t   O   c  \0  \0  \0 002  \0  \0  \0 002

indicates index version 2, as it has the magic byte sequence in front of '\xFFt0c'. Most version 1 indexes will have 2 zeros in the first two bytes:

0000000  \0  \0  \0  \0  \0  \0  \0 001  \0  \0  \0 003

I'm picking this up again and working on it more.  Its not dead.
  

I've found that accessing a Git pack file over a network file system like NFS or SMB is kinda slow. The issue is we do many reads scattered throughout the file. Its hard for the client to batch up reads and hide the network latency.

You may get better performance by building Git without mmap support:

	make NO_MMAP=1

but that is going to hurt access to local files.