> Thanks Lucas, for your proposal. I would recommend in-lining new > versions in the same thread, it makes it easier to review and also to > note what comments were left in previous versions. Oops, sorry :-( > This was a good read! Really nice! Thanks! > One thing to keep in mind is we already have: > - git status > - git describe > Both of them are used to provide summary about the repository in some > sense. How do we differentiate between these two and the new command. > Rhetorical: > - Does 'git metadata' differentiate itself enough to imply what it does? By now, the main idea is to bring some functionality from rev-parse, although I think that there's room for placing other information, like remotes, submodules, packfiles and so on. I don't think that it is related to status or describe, as status is more related to the working tree and index status and describe is more related to the history itself. By "metadata" I mean the data about the repository itself. > - Does it convey that it should be used to retrieve repository > information? > - Should we consider 'git repo-info', 'git info', 'git context', 'git > repo-query'? Perhaps `git repo-info` would be a better name, as "metadata" could be too much generic as it is in some ways a synonym of the name of the other commands > We know that 'git rev-parse' outputs in a human readable, would that be > the default here too? The original idea (from https://git.github.io/SoC-2025-Ideas/) was to format it as a JSON output. My only concern here is that if I used the JSON format in some situations and a plain string format in other situations it would lead to a lack of consistency on what it is expected to output. That is, keeping in mind the Unix philosophy of "do one thing and do it well", avoiding doing to much and becoming another rev-parse. > There are a lot more options under the 'Options for Files' section of > the 'git rev-parse' manpage, it would nice to highlight that this is > mostly what we're looking at. Nice idea! I didn't extensively listing what should be displayed in this JSON because I think there's still room for it being decided, but having a reference on what can be potential features mades it a lot clear. I'll included that. > It would be nice to add subsections maybe: > '{"refs": {...}, ..., "objects": {...}}' At first, my idea was to bring more information to this json, e.g. the hashes of branches, tags and remote branches, the submodule remote and so on. But after Patrick's review it's more focused on the features of rev-parse that are not exactly related to "rev parsing" but somehow are placed there. > Thanks > - Karthik Thanks for your review, Karthik! There's a few hours left, I'll try to do my best considering what you told me here. Very good insights, I must say.
