RE: [found the culprit]

[Drew Adams]

> > `Z' should be its own inverse.
> 
> This is a reasonable principle, but there is a reason to deviate from
> it here.  The uncompressed tar format is so rarely used (partly because of
> the lack of actual tape drives, and partly because of change in the
> relative cost of CPU cycles and storage space) that having a convenient
> key to get _to_ it is unimportant.  The unpacked and compressed-tar
> states, however, are both deserving of such a key.  Therefore, whatever
> behavior (unpack or compress) we choose to apply to a .tar will not be
> inverted by a second Z -- because the initial state is presumed to be
> undesirable.
> 
> For example, on some machines I use, "git archive" cannot produce
> compressed archives.  Having Z compress its raw .tar output would be,
> to me, a useful way of working around that limitation.  But other users
> might prefer that Z unpack a .tar -- and then repack the resulting
> (hopefully single) directory into a .tgz.
> 
> Could Z query for which behavior to use in this (rare) case?  That
> would provide an intuitive reason why a second Z would not necessarily
> reverse the process.  (The query could even say so explicitly if it helped.)

It sounds like you are arguing for `Z' to in fact be
its own inverse, and in the case of tar.gz and .tgz
to consider, as Stefan suggested, that that's the
inverse state from extracted (un(tarred+compressed)).

And you are saying (again, like Stefan), that the
plain tar case is now an outlier, so it can be
ignored, at least by `Z'.  That's OK by me.  Maybe
we should have a (new) separate command that deals
with plain tars (creation and production from tar.gz),
and perhaps that command needs no key.

I don't have a problem with that, if that's the state
of the real use cases now.

A zip archive, like a tar, need not contain a directory.
It sounds like both could be handled the same way.
If that leaves some tar cases out in the cold then they
can perhaps be warmed up with a new command.

And we can maybe get updated doc and a NEWS entry... ;-)