> Ok, so each key has a corresponding callback that is used to get its > value. This works fine when we have one operation/callback per key, but > I could see this being a bit inflexible in cases where performing a > single operation could be expected to generate multiple keys worth of > information at a time. For git-repo-info it wouldn't be a problem, as we return one value per requested key. However, I plan to add a feature in the future for requesting a group of fields. For example: $ git repo info layout layout.bare=true layout.shallow=false which, of course, is not what exactly you mean :-). But it is a similar problem of requesting one key and getting several key-value pairs. > I certainly see this being the case with git-repo-stats where, for > example, interating over references will produce multiple keyvalues > indicating the number of branches, tags, remotes, etc. But, maybe for > git-repo-info this will not be as much of a concern? For git-repo-info it isn't, at least by the planned set of values. However, given that I have plans to add the previous feature, I can try to make it flexible for doing things like: $ git repo stats object.count object.count.blob=123 object.count.tree=456 object.count.commit=789 So you can use the same code for outputting git-repo-stats data. By now, I plan to finish the basic functionality (i.e. finishing this "skeleton" and adding the rest of the proposed fields), then I'll think about this feature. I think the current solution is simple enough to being refactored to support this kind of thing in the future. > If the user does not input any keys, we simply do nothing. I do wonder > if this is really the best default behavior. In previous versions it returned all the available fields. There was a `--allow-empty` flag that allowed to request no field. After the discussion in [1] we agreed that it would be better to return nothing by default and add a `--all` flag for returning all the fields (or a default set of fields).
