Improve git-prune -n output

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.

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.

---
 builtin-prune.c |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)

index 7290e6d..e3bcf5f 100644
@@ -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 );
 		return 0;
 	}
 	unlink(mkpath("%s/%s", path, filename));

1.4.2.3

The only problem with that is that the type string is of variable width, while the hash is fixed; hence <hash> <type> is more visually appealing than <type> <hash>.

Does it really matter anyway? Some sort of processing would have to happen before using git-prune output as git-cat-file parameters...

git-prune -n |
while read hash type
do
git-cat-file $type $hash
done

Andy

Dr Andy Parkins, M Eng (hons), MIEE

I would rather question if the alignment really matters. You could always printf("%10s %s\n", type, hex) if you really cared, though.

which is probably not the way in which the command output is going to be used. I'd expect a sequence more like:

	$ git prune -n
	blob deadbeefdeadbeef...
        commit deadbeefdeadbeef...
        ...

The user would not just pipe all of the output to cat-file, but would pick ones that are meaningful to be cat'ed (commit and perhaps blob but definitely not tree). And the cue to pick which ones would likely to be the object type not hash, so in that sense type-then-hash might be easier to read.

Having said that, a potentially useful application would be "a backup before prune" which can be done more easily if you use
hash-then-type: "git prune -n | git pack-objects backup"

So while I do not think it matters that much, I slightly prefer hash-then-type better than type-then-hash.

I don't think we need to enforce this rule in particular too rigorously since in comparison with other style slips, it doesn't put you off by unusual styling when you are reading the code, its only effect at all is slight vertical space waste (but it isn't a pure loss anyway, for that matter).

Dear diary, on Thu, Oct 26, 2006 at 07:33:35PM CEST, I got a letter where Andy Whitcroft <[email protected]> said that...

Seconded and please use just 'unknown' for the type string, so that you can split the lines on spaces in scripts.

Besides, in what situation do we actually get the unknown output?

Thanks,

				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1

I do not have an objection to what this does, except I wonder if somebody's script relies on parsing this output already.

It is customary to have one empty line before the S-o-b: line.

I did think of that, but the existing output looked pretty non-useful for easy parsing because of the fact that filenames where being printed instead of hashes. If I were given free reign I think I'd want to drop the "would prune" message as well.

I didn't do it. Git did :-) I'll keep an eye out for it from now on. Apologies (as usual)

Andy

Dr Andrew Parkins, M Eng (Hons), AMIEE

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.

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.

---
Fixes issues from...

Junio C Hamano
Do not leave blank inside () pairs.
Do not enclose a single statement in {}.
No longer uses strcpy()

Petr Baudis
"unknown type" is now simply "unknown"

Andy Parkins
No longer outputs "would prune"

 builtin-prune.c |    8 +++++++-
 1 files changed, 7 insertions(+), 1 deletions(-)

index 7290e6d..b8b2d05 100644
@@ -16,8 +16,14 @@ static struct rev_info revs;
 
 static int prune_object(char *path, const char *filename, const unsigned char 

*sha1)
{
+ char buf[20];
+ const char *type;
+
if (show_only) {
- printf("would prune %s/%s\n", path, filename);
+ type = buf;
+ if (sha1_object_info(sha1, type, NULL))
+ type = "unknown";
+ printf("%s %s\n", sha1_to_hex(sha1), type );
return 0;
}
unlink(mkpath("%s/%s", path, filename));

1.4.3.3.g5bca6

This allowed to 'rm -f' [some] of what git-prune -n shows.

Did anybody used that? I don't know...

Well, you can always use git-lost-found. Perhaps it would be better to add -n option to git-lost-found to not create refs in $GIT_DIR/lost-found/ directory.

Sorry for being late with that suggestion.

Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Yes and probably no because the output did not have enough clues to help picking which ones to remove. If the command said something like this:

	.git/objetcts/11/feed0... ;# commit 2006-08-28: WIP for	"foo"

it might have been a good clue and would have made sense, though.