Various CLI improvements #2811
Various CLI improvements #2811
Conversation
In all cases documentation was missing from the manual and the bash completion was incorrectly assigning it as a boolean option.
The output is much more readable sorted. I can't think of any reason you'd want it unsorted (which is essentially dentry order).
Allow printing the revision along with the ref. This is very convenient for looping over the refs in a shell as well as for quickly seeing which refs are pointed to the same commit.
The only other way to get the remote ref revision from the CLI is to scrape the output of `ostree remote summary` or pull the commit. The revision is already there in the summary's ref map, so might as well add an option to show it.
While `--print-metadata-key` is very useful, it's not that helpful if you don't know what the keys are.
Like with commit metadata, it's useful to list and print metadata keys are in a summary file. This adds helpers to do that.
There was a problem hiding this comment.
LGTM. Thanks for the well split-out patches!
Restarted CI. Will let @cgwalters have a look and merge.
| g_autoptr(GVariant) metadata = NULL; | ||
| g_autoptr(GVariant) value = NULL; | ||
|
|
||
| summary = g_variant_new_from_bytes (OSTREE_SUMMARY_GVARIANT_FORMAT, |
There was a problem hiding this comment.
This is all fine as is but personally I've been trying to convert the whole codebase to declare-and-initialize because it's simply shorter, also matches how e.g. Rust works, and works better with goto out and not having implicitly nullable pointers.
I imagine you work on other codebases that still use C89 separation between declaration and init, but hopefully we can agree to keep this one using declare-and-initialize.
There was a problem hiding this comment.
That's fair. I split it for 2 reasons.
One is that I personally think sometimes it gets pretty busy with the initializer on the same line with an autoptr declaration. The other is that I have had gcc whine about using using uninitialized variables before when autoptr variables aren't explicitly initialized to NULL. Which seems like a compiler bug but there is some logic to it in certain scenarios.
Anyways, I'll be sure to do the full initialization next time.
There was a problem hiding this comment.
The other is that I have had gcc whine about using using uninitialized variables before when autoptr variables aren't explicitly initialized to NULL.
I'm talking about declare-and-initialize, so there's no point at which it's set to NULL.
There was a problem hiding this comment.
I hope I'm remembering this right, but I am talking about declare-and-initialize of a g_autoptr. I believe what happened is that the compiler decided that the initialization code could be run later, but then the __attribute__((cleanup(func))) code would warn that it was potentially using an uninitialized variable. As as said, likely a gcc bug since the presence of the cleanup attribute means it shouldn't split the initializer. I've only seen it a few times, though.
|
Well, something clearly broke WRT our space checks, but it's also not related to this PR |
|
@cgwalters: Overrode contexts on behalf of cgwalters: continuous-integration/jenkins/pr-merge In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
Often I want to quickly inspect local and remote repos to see what's currently in them. While it's often better to write something that uses the API to get the precise desired information, the CLI is very handy for quickly assessing the situation. This adds some options to various CLI builtins to expose or improve that information.