Andy Parkins <andyparkins@xxxxxxxxx> writes:
> 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.
> ... 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.
-
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