On 02/03/2013 11:41 PM, Robert Clausecker wrote:
> Am Sonntag, den 03.02.2013, 21:55 +0530 schrieb Sitaram Chamarty:
>> Could you help me understand why piping it to tar (actually 'tar -C
>> /dest/dir -x') is not sufficient to achieve what you want?
> Piping the output of git archive into tar is of course a possible
> solution; I just don't like the fact that you need to pipe the output
> into a separate program to do something that should be possible with a
> simple switch and not an extra command. It feels unintuitive and like a
> workaround to make an archive just to unpack it on-the-fly. Also, adding
> such a command (or at least documenting the way to do this using a pipe
> to tar somewhere in the man pages) is a small and simple change that
> improves usability.

I realise it appears to be the fashion these days to get away from the
Unix philosophy of having different tools do different things and
combining them as needed.

Ignoring the option-heavy GNU, and looking at the more traditional BSD
tar manpage [1], I notice the following flags that could still be
potentially needed by someone running 'git archive': '-t' (instead of
'-x'), '-C dir', '--exclude/include', '-k', '-m', '--numeric-owner', -o,
-P, -p, -q, -s, -T, -U, -v, -w, and -X.

And I'm ignoring the esoteric ones like "--chroot" and "-S" (sparse mode).

How many of these options would you like included in git?  And if you
say "I don't need any of those; I just need '-x'", that's not relevant.
 Someone else may need any or all of those flags, and if you accept "-x"
you have to accept some of the others too.

Also, I often want to deploy to a different host, and I might do that
like so:

    git archive ... | ssh host tar -C /deploy/dir -x

Why not put that ssh functionality into git also?

What about computing a checksum and putting out a "sha1sums.txt" file?
People do that also.  How about a flag for that?

Where does this end?

[1]: http://www.unix.com/man-page/FreeBSD/1/tar/

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to