Andy Parkins <andyparkins@xxxxxxxxx> writes:
> prune_object() in show_only mode would previously just show the path to the
> object that would be deleted. The path the object is stored in shouldn't be
> shown to users, they only know about sha1 identifiers so show that instead.
I do not have an objection to what this does, except I wonder if
somebody's script relies on parsing this output already.
> Further, the sha1 alone isn't that useful for examining what is going to be
> deleted. This patch also adds the object type to the output, which makes it
> easy to pick out, say, the commits and use git-show to display them.
> Signed-off-by: Andy Parkins <andyparkins@xxxxxxxxx>
It is customary to have one empty line before the S-o-b: line.
> ---
> builtin-prune.c | 7 ++++++-
> 1 files changed, 6 insertions(+), 1 deletions(-)
>
> diff --git a/builtin-prune.c b/builtin-prune.c
> index 7290e6d..e3bcf5f 100644
> --- a/builtin-prune.c
> +++ b/builtin-prune.c
> @@ -16,8 +16,13 @@ static struct rev_info revs;
>
> static int prune_object(char *path, const char *filename, const unsigned char *sha1)
> {
> + char type[20];
> +
> if (show_only) {
> - printf("would prune %s/%s\n", path, filename);
> + if (sha1_object_info(sha1, type, NULL)) {
> + strcpy( type, "unknown type" );
> + }
> + printf("would prune %s %s\n", sha1_to_hex( sha1 ), type );
Style.
- We do not leave blank inside () pairs.
- We do not enclose a single statement in {}.
Perhaps an extra variable of type "char *" that initially point
at type[] but later points at the "unknown" might be more
efficient, but that being on the error path I do not think
saving one strcpy() that way is worth it.
So, just the style and a slight worry that this _might_ break
people's scripts.
Objections?
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html