From: "Thomas Gummerer" <t.gummerer@xxxxxxxxx> Sent: Thursday, May 03, 2012
6:25 PM
I have been drafting the Version 5 of the index format over the past
few days with the help of Thomas Rast, Michael Haggerty, cmn and
barrbrain on IRC. It will save with prefix compression on the path, and
using a crc32 over the stat data, instead of the full data, since it is
only
used for checking if the file is changed. (Thanks Michael Haggerty for
this hint. Unless we are missing something this will save another
~4 MB on the Webkit index.
GIT index format
================
= The git index file has the following format
xxx
== Directory entry
Directory entries are sorted in lexicographic order by the name
of their path starting with the root.
Path names (variable length) relative to top level directory (without the
leading slash). '/' is used as path separator. '.' indicates the root
directory. The special patch components ".." and ".git" (without
quotes)
are disallowed. Trailing slash is also disallowed.
Does the prohibition of ".git" prevent the potential for versioning of the
.git directory itself (e.g. .gitignore the pack & objects themselves)?
It should be possible for one's current repo status to be tracked and
summarised by a single sha1, say as an indepenedent branch, as you would the
code itself.
[my use case is in a managed environment where one has plenty of networked
project storage, but no real availability of a network server, so anybody
and his mate could corrupt ones network repo with badly thought through
tweaks. The lack of a server is the root cause, but that's not something the
project can fix, so thinks ... 'version the meta data...']
I can see that the lack of the leading "/", and the ".." are a policy
statement about paths being relative to top level directory, with direct
path referencing. The typical avoidance of ".git" should be a note about how
regular git works, rather than an absolute prohibition.
Philip
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html