From: Derrick Stolee <stolee@gmail.com>
To: "Nguyễn Thái Ngọc Duy" <pclouds@gmail.com>, git@vger.kernel.org
Subject: Re: [PATCH 1/8] ls-files: add --json to dump the index
Date: Wed, 19 Jun 2019 09:03:27 -0400 [thread overview]
Message-ID: <e3b8d7bf-486d-d52f-9a33-6a7ff837552e@gmail.com> (raw)
In-Reply-To: <20190619095858.30124-2-pclouds@gmail.com>
On 6/19/2019 5:58 AM, Nguyễn Thái Ngọc Duy wrote:
> So far we don't have a command to basically dump the index file out,
> with all its glory details. Checking some info, for example, stat
> time, usually involves either writing new code or firing up "xxd" and
> decoding values by yourself.
>
> This --json is supposed to help that. It dumps the index in a human
> readable format but also easy to be processed with tools. And it will
> print almost enough info to reconstruct the index later.
In an earlier message, I stated that I like the idea of this feature.
I know that you wanted to get that feedback before working too hard on
the patch series, so now that interest is declared, please add some tests
that verify this output looks as you expect.
> In this patch we only dump the main part, not extensions. But at the
> end of the series, the entire index is dumped. The end result could be
> very verbose even on a small repository such as git.git.
I would expect this commit to include a complete "output matches expected"
test, and the later patches can update the index to include these
extensions then verify that their sections appear in the output using
a grep.
> +--json::
> + Dump the entire index content in JSON format. This is for
> + debugging purposes and the JSON structure may change from time
> + to time.
> +
"...purposes and the JSON structure may change from time to time" may be better
as "...purposes. The JSON structure is subject to change."
> + OPT_BOOL(0, "json", &show_json,
> + N_("dump index content in json format")),
We should probably use "JSON" here in the help text.
> - show_files(the_repository, &dir);
> -
> - if (show_resolve_undo)
> - show_ru_info(the_repository->index);
> + if (!show_json) {
> + show_files(the_repository, &dir);
> +
> + if (show_resolve_undo)
> + show_ru_info(the_repository->index);
> + } else {
> + struct json_writer jw = JSON_WRITER_INIT;
> +
> + discard_index(the_repository->index);
> + the_repository->index->jw = &jw;
> + if (repo_read_index(the_repository) < 0)
> + die("index file corrupt");
> + puts(jw.json.buf);
> + the_repository->index->jw = NULL;
> + jw_release(&jw);
> + }
>
> if (ps_matched) {
> int bad;
I see this 'ps_matched' condition at the end, which is related to
the '--error-unmatch' option. I added "--error-unmatch foo" to my
command and got the appropriate error message:
error: pathspec 'foo' did not match any file(s) known to git
Did you forget to 'git add'?
This was sent to stderr while the JSON was in stdout, so this should
be appropriate to allow both options. Just pointing it out to make
sure this is intended.
> +void jw_object_stat_data(struct json_writer *jw, const char *name,
> + const struct stat_data *sd)
> +{
> + jw_object_inline_begin_object(jw, name);
> + jw_object_intmax(jw, "st_ctime.sec", sd->sd_ctime.sec);
> + jw_object_intmax(jw, "st_ctime.nsec", sd->sd_ctime.nsec);
> + jw_object_intmax(jw, "st_mtime.sec", sd->sd_mtime.sec);
> + jw_object_intmax(jw, "st_mtime.nsec", sd->sd_mtime.nsec);
> + jw_object_intmax(jw, "st_dev", sd->sd_dev);
> + jw_object_intmax(jw, "st_ino", sd->sd_ino);
> + jw_object_intmax(jw, "st_uid", sd->sd_uid);
> + jw_object_intmax(jw, "st_gid", sd->sd_gid);
> + jw_object_intmax(jw, "st_size", sd->sd_size);
> + jw_end(jw);
> +}
If these are all part of the same object, are the "st_" prefixes
necessary for every member?
> + /*
> + * again redundant info, just so you don't have to decode
> + * flags values manually
> + */
> + if (ce->ce_flags & CE_VALID)
> + jw_object_true(jw, "assume-unchanged");
> + if (ce->ce_flags & CE_INTENT_TO_ADD)
> + jw_object_true(jw, "intent-to-add");
> + if (ce->ce_flags & CE_SKIP_WORKTREE)
> + jw_object_true(jw, "skip-worktree");
> + if (ce_stage(ce))
> + jw_object_intmax(jw, "stage", ce_stage(ce));
I'm really glad these flags are getting expanded! Much easier to
understand what's going on this way.
> + if (istate->jw) {
> + jw_object_begin(istate->jw, jw_pretty);
> + jw_object_intmax(istate->jw, "version", istate->version);
> + jw_object_string(istate->jw, "oid", oid_to_hex(&istate->oid));
> + jw_object_intmax(istate->jw, "st_mtime.sec", istate->timestamp.sec);
> + jw_object_intmax(istate->jw, "st_mtime.nsec", istate->timestamp.nsec);
Here, the "st_" prefixes are not on every member, but would it
be confusing if they were not there? Also, including a "." in
a member name may be troublesome for JSON, as that typically
means we are accessing a member of an object. Perhaps use _sec
and _nsec here and in the earlier stat_data block.
Thanks,
-Stolee
next prev parent reply other threads:[~2019-06-19 13:03 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-19 9:58 [PATCH 0/8] Add 'ls-files --json' to dump the index in json Nguyễn Thái Ngọc Duy
2019-06-19 9:58 ` [PATCH 1/8] ls-files: add --json to dump the index Nguyễn Thái Ngọc Duy
2019-06-19 10:30 ` Ævar Arnfjörð Bjarmason
2019-06-19 13:03 ` Derrick Stolee [this message]
2019-06-21 13:04 ` Johannes Schindelin
2019-06-24 12:50 ` Duy Nguyen
2019-06-19 9:58 ` [PATCH 2/8] split-index.c: dump "link" extension as json Nguyễn Thái Ngọc Duy
2019-06-19 9:58 ` [PATCH 3/8] fsmonitor.c: dump "FSMN" " Nguyễn Thái Ngọc Duy
2019-06-19 9:58 ` [PATCH 4/8] resolve-undo.c: dump "REUC" " Nguyễn Thái Ngọc Duy
2019-06-19 13:16 ` Derrick Stolee
2019-06-19 9:58 ` [PATCH 5/8] read-cache.c: dump "EOIE" " Nguyễn Thái Ngọc Duy
2019-06-19 9:58 ` [PATCH 6/8] read-cache.c: dump "IEOT" " Nguyễn Thái Ngọc Duy
2019-06-19 13:18 ` Derrick Stolee
2019-06-19 13:24 ` Duy Nguyen
2019-06-19 14:26 ` Derrick Stolee
2019-06-19 9:58 ` [PATCH 7/8] cache-tree.c: dump "TREE" " Nguyễn Thái Ngọc Duy
2019-06-19 9:58 ` [PATCH 8/8] dir.c: dump "UNTR" " Nguyễn Thái Ngọc Duy
2019-06-19 11:58 ` [PATCH 0/8] Add 'ls-files --json' to dump the index in json Derrick Stolee
2019-06-19 12:42 ` Duy Nguyen
2019-06-19 12:48 ` Derrick Stolee
2019-06-19 19:17 ` Jeff King
2019-06-21 8:37 ` Duy Nguyen
2019-06-21 20:48 ` Jeff King
2019-06-21 13:16 ` Johannes Schindelin
2019-06-21 13:49 ` Duy Nguyen
2019-06-21 15:10 ` Junio C Hamano
2019-06-21 20:52 ` Jeff King
2019-06-24 9:35 ` Johannes Schindelin
2019-06-24 9:33 ` Johannes Schindelin
2019-06-24 9:35 ` Duy Nguyen
2019-06-21 20:51 ` Jeff King
2019-06-24 9:52 ` Johannes Schindelin
2019-06-20 4:00 ` Junio C Hamano
2019-06-20 19:12 ` Jeff Hostetler
2019-06-21 23:30 ` brian m. carlson
2019-06-22 2:54 ` Duy Nguyen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e3b8d7bf-486d-d52f-9a33-6a7ff837552e@gmail.com \
--to=stolee@gmail.com \
--cc=git@vger.kernel.org \
--cc=pclouds@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox