On 6/20/2018 11:07 AM, Duy Nguyen wrote:
On Wed, Jun 20, 2018 at 3:33 PM Derrick Stolee <stolee@xxxxxxxxx> wrote:
On 6/7/2018 2:31 PM, Duy Nguyen wrote:
On Thu, Jun 7, 2018 at 4:03 PM, Derrick Stolee <stolee@xxxxxxxxx> wrote:
diff --git a/Documentation/git-midx.txt b/Documentation/git-midx.txt
index dcaeb1a91b..919283fdd8 100644
--- a/Documentation/git-midx.txt
+++ b/Documentation/git-midx.txt
@@ -23,6 +23,11 @@ OPTIONS
<dir>/packs/multi-pack-index for the current MIDX file, and
<dir>/packs for the pack-files to index.
+read::
+ When given as the verb, read the current MIDX file and output
+ basic information about its contents. Used for debugging
+ purposes only.
On second thought. If you just need a temporary debugging interface,
adding a program in t/helper may be a better option. In the end we
might still need 'read' to dump a file out, but we should have some
stable output format (and json might be a good choice).
My intention with this 'read' pattern in the MIDX (and commit-graph) is
two-fold:
1. We can test that we are writing the correct data in our test suite. A
test-tool builtin would suffice for this purpose.
2. We can help trouble-shoot users who may be having trouble with their
MIDX files. Having the subcommand in a plumbing command allows us to do
this in the shipped versions of Git.
Maybe this second purpose isn't enough to justify the feature in Git and
we should move this to the test-tool, especially with the 'verify' mode
coming in a second series. Note that a 'verify' mode doesn't satisfy
item (1).
Yeah I think normally we just have some "fsck" thing to verify when
things go bad. If you need more than that I think you just ask the
user to send the .midx to you (with full understanding of potentially
revealing confidential info and stuff). It'll be faster than
instructing them to "run this command", "ok, run another command"....
I thought of suggesting a command to dump the midx file in readable
form (like json), but I think if fsck fails then chances of that
command successfully dumping may be very low.
Either way, if the command is meant for troubleshooting, I think it
should be added at the end when the whole midx file is implemented and
understood and we see what we need to troubleshoot. Adding small
pieces of changes from patch to patch makes it really hard to see if
it helps troubleshooting at all, it just helps the first purpose.
I'll abandon point (2) for the later 'verify' patch series. Adding the
test helper early allows tests to demonstrate that each patch does the
right thing, and that we don't miss testing something.
Thanks,
-Stolee
