Re: Draft v1.5.0 release notes

Steven Grimm [off-list ref] wrote:

Junio C Hamano wrote:

quoted

- 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.

Or even in public ones, but where access by dumb clients isn't
offered (only anonymous or ssh based git native protocol is used).

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's an interesting idea.  Most users don't invoke init-db directly
however, they are using clone to copy someone else's repository.
But that option could easily be offered on both commands, with
clone just passing it through to init-db.
 

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.

Actually I wonder if "--min-version=current" shouldn't just be the
default.  Most users are going to init-db or clone locally and use
only the current version of Git (or later) against that repository.

Though that probably would break someone who runs multiple versions
of Git on the same system, because they have some strange reason
for doing so[*1*].  And it would certainly cause problems for
users who then rsync that repository (or scp it) to a webhost and
expect users with older versions of Git to be able to access it
with a commit-walker client.  But that would be less of a problem
if we could teach users to first clone their repository before
publishing it, e.g.:

    git clone --bare --min-version=1.2 . ../myproj.git


*1*: I'm not talking about Git developers here.  I think most Git
     developers run a `production` version of Git that they use for
     actual revisioning, and other versions for testing, and those
     testing versions are only used against testing repositories
     that hold non-live data.

-- 
Shawn.