Re: [PATCH] Improve git-prune -n output

From: Junio C Hamano <junkio@cox.net>
Date: Oct 27, 2006, 09:09 UTC
Message-ID: <7vslhagm6n.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <200610270920.06064.andyparkins@gmail.com>

Andy Parkins <andyparkins@gmail.com> writes:

Show 5 quoted lines

> 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?

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

Show 8 quoted lines

> ... 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

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.