Junio C Hamano wrote:
- There is a configuration variable core.legacyheaders that
changes the format of loose objects so that they are more
efficient to pack and to send out of the repository over git
native protocol, since v1.4.2. However, this format cannot
be read by git older than that version; people fetching from
your repository using older clients over dumb transports
(e.g. http) using older versions of git will also be
affected. This is not enabled by default.
- Since v1.4.3, configuration repack.usedeltabaseoffset allows
packfile to be created in more space efficient format, which
cannot be read by git older than that version. This is not
enabled by default.
For people in non-public development environments, where there's
absolutely no possibility of someone hitting a repo with an old client,
presumably these options should both be enabled. I wonder if it makes
sense to add an option to git-init-db to create a configuration file
with all the latest stuff enabled -- or better still, something like
git-init-db --min-version=1.4.2
that would enable all the non-backward-compatible stuff in the newly
created repository. And then a special case "--min-version=current" to
use all the most optimal settings for the current release, useful in
environments like corporate LANs where the tool versions are centrally
managed.
Likewise, something like
git-repo-config --min-version=1.5.0
could be used to set all the options in an existing repo (presumably
this would not allow you to move backwards, just upgrade) for cases
where clients are known to have all upgraded to at least a particular
version.
Maybe that last purpose would be better served by a "git-upgrade"
command that, for example, could rebuild old packfiles in the new more
efficient format and write out the appropriate configuration. Though one
would have to take pains to point out that running that command was NOT
a required step when upgrading to a new git release, and would in fact
be a bad idea for projects being accessed by older clients.
-Steve
-
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