Junio C Hamano <junkio@xxxxxxx> writes:
> Andy Parkins <andyparkins@xxxxxxxxx> writes:
>
>> On Wednesday 2007 February 14 03:14, Junio C Hamano wrote:
>>
>>> - There is a configuration variable core.legacyheaders that
>>
>>> The above two are not enabled by default and you explicitly have
>>> to ask for them, because these two features make repositories
>>
>> It isn't really the case that you have to _enable_ legacyheaders? It defaults
>> to on already. You actually have to disable legacyheaders.
>
> Ah, true. What it should have stressed is that we currently
> default to the safer, backward compatible behaviour, and you have
> to explicitly ask to use more efficient but incompatible
> encoding by setting core.legacyheaders to false.
So this will be the updated explanation.
-- >8 --
diff --git a/Documentation/RelNotes-1.5.0.txt b/Documentation/RelNotes-1.5.0.txt
index f0120e1..0989ded 100644
--- a/Documentation/RelNotes-1.5.0.txt
+++ b/Documentation/RelNotes-1.5.0.txt
@@ -25,12 +25,18 @@ Specifically, the available options are:
older clients over dumb transports (e.g. http) using older
versions of git will also be affected.
+ To let git use the new loose object format, you have to
+ set core.legacyheaders to false.
+
- 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.
-The above two are not enabled by default and you explicitly have
-to ask for them, because these two features make repositories
+ To let git use the new format for packfiles, you have to
+ set repack.usedeltabaseoffset to true.
+
+The above two new features are not enabled by default and you
+have explicitly to ask for them, because they make repositories
unreadable by older versions of git, and in v1.5.0 we still do
not enable them by default for the same reason. We will change
this default probably 1 year after 1.4.2's release, when it is
-
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