[PATCH] doc/technical: remove outdated MIDX default note

Multi-pack-index files are used by default since
commit 18e449f86b74bab35b150549c8342d252fe7ae00, so the
outdated note was misleading.

Signed-off-by: Eric Wong <redacted>
---
 Documentation/technical/multi-pack-index.txt | 2 --
 1 file changed, 2 deletions(-)

diff --git a/Documentation/technical/multi-pack-index.txt b/Documentation/technical/multi-pack-index.txt
index 1a73c3ee20..2038fb7995 100644
--- a/Documentation/technical/multi-pack-index.txt
+++ b/Documentation/technical/multi-pack-index.txt

@@ -36,8 +36,6 @@ Design Details
   directory of an alternate. It refers only to packfiles in that
   same directory.
 
-- The core.multiPackIndex config setting must be on to consume MIDX files.
-
 - The file format includes parameters for the object ID hash
   function, so a future change of hash algorithm does not require
   a change in format.

On 9/22/2021 6:13 PM, Eric Wong wrote:

Multi-pack-index files are used by default since
commit 18e449f86b74bab35b150549c8342d252fe7ae00, so the
outdated note was misleading.

You are correct that the note is misleading, but it is still correct.

A user can _disable_ reading MIDX files by setting core.multiPackIndex
to false. If this was in the user-facing docs, not the technical docs,
then I might push back on trying to make that distinction.

-- The core.multiPackIndex config setting must be on to consume MIDX files.
-

As it is, this deletion is fine.

A nit on your commit message: format commit references like this:

  18e449f86 (midx: enable core.multiPackIndex by default, 2020-09-25)

Thanks,
-Stolee

On Thu, Sep 23, 2021 at 09:47:03AM -0400, Derrick Stolee wrote:

On 9/22/2021 6:13 PM, Eric Wong wrote:

quoted

Multi-pack-index files are used by default since
commit 18e449f86b74bab35b150549c8342d252fe7ae00, so the
outdated note was misleading.

You are correct that the note is misleading, but it is still correct.

A user can _disable_ reading MIDX files by setting core.multiPackIndex
to false. If this was in the user-facing docs, not the technical docs,
then I might push back on trying to make that distinction.

It may present a fuller picture to instead say:

  The core.multiPackIndex config setting must be on (which is the default)
  to consume MIDX files. Setting it to `false` prevents Git from reading a
  MIDX file, even if one exists.

Thanks,
Taylor

Taylor Blau [off-list ref] wrote:

On Thu, Sep 23, 2021 at 09:47:03AM -0400, Derrick Stolee wrote:

quoted

On 9/22/2021 6:13 PM, Eric Wong wrote:

quoted

Multi-pack-index files are used by default since
commit 18e449f86b74bab35b150549c8342d252fe7ae00, so the
outdated note was misleading.

You are correct that the note is misleading, but it is still correct.

A user can _disable_ reading MIDX files by setting core.multiPackIndex
to false. If this was in the user-facing docs, not the technical docs,
then I might push back on trying to make that distinction.

It may present a fuller picture to instead say:

  The core.multiPackIndex config setting must be on (which is the default)
  to consume MIDX files. Setting it to `false` prevents Git from reading a
  MIDX file, even if one exists.

Ah, thanks, I'll just use your text.

---------8<----------
Subject: [PATCH] doc/technical: update note about core.multiPackIndex

MIDX files are used by default since commit d0fa539bc569
(doc/technical: remove outdated MIDX default note, 2021-09-22)

Helped-by: Taylor Blau [off-list ref]
Signed-off-by: Eric Wong <redacted>
---
 Documentation/technical/multi-pack-index.txt | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Documentation/technical/multi-pack-index.txt b/Documentation/technical/multi-pack-index.txt
index 1a73c3ee203e..86f40f24909a 100644
--- a/Documentation/technical/multi-pack-index.txt
+++ b/Documentation/technical/multi-pack-index.txt

@@ -36,7 +36,9 @@ Design Details
   directory of an alternate. It refers only to packfiles in that
   same directory.
 
-- The core.multiPackIndex config setting must be on to consume MIDX files.
+- The core.multiPackIndex config setting must be on (which is the
+  default) to consume MIDX files.  Setting it to `false` prevents
+  Git from reading a MIDX file, even if one exists.
 
 - The file format includes parameters for the object ID hash
   function, so a future change of hash algorithm does not require

On Thu, Sep 23, 2021 at 08:12:52PM +0000, Eric Wong wrote:

Subject: [PATCH] doc/technical: update note about core.multiPackIndex

MIDX files are used by default since commit d0fa539bc569
(doc/technical: remove outdated MIDX default note, 2021-09-22)

Helped-by: Taylor Blau [off-list ref]
Signed-off-by: Eric Wong <redacted>
---

Thanks; this version looks good to me.

Thanks,
Taylor

MIDX files are used by default since commit 18e449f86b74
(midx: enable core.multiPackIndex by default, 2020-09-25)

Helped-by: Taylor Blau [off-list ref]
Signed-off-by: Eric Wong <redacted>
---
 v3: I cited the wrong commit in the commit message of v2 :x

 Documentation/technical/multi-pack-index.txt | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Documentation/technical/multi-pack-index.txt b/Documentation/technical/multi-pack-index.txt
index 1a73c3ee203e..86f40f24909a 100644
--- a/Documentation/technical/multi-pack-index.txt
+++ b/Documentation/technical/multi-pack-index.txt

@@ -36,7 +36,9 @@ Design Details
   directory of an alternate. It refers only to packfiles in that
   same directory.
 
-- The core.multiPackIndex config setting must be on to consume MIDX files.
+- The core.multiPackIndex config setting must be on (which is the
+  default) to consume MIDX files.  Setting it to `false` prevents
+  Git from reading a MIDX file, even if one exists.
 
 - The file format includes parameters for the object ID hash
   function, so a future change of hash algorithm does not require

On 9/24/2021 7:11 AM, Eric Wong wrote:

MIDX files are used by default since commit 18e449f86b74
(midx: enable core.multiPackIndex by default, 2020-09-25)

Helped-by: Taylor Blau [off-list ref]
Signed-off-by: Eric Wong <redacted>
---
 v3: I cited the wrong commit in the commit message of v2 :x

Good catch.
 

This looks good to me, too!

Thanks,
-Stolee