On Sun, Feb 3, 2013 at 7:42 PM, Sitaram Chamarty <sitar...@gmail.com> wrote:
> 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.

OP did not ask about tar so I do not see why any of these tar options
are relevant.  It seems like what he really wants is 'git archive
--format=native' , maybe.   You can almost create this option by

   git config tar.native.command "tar -x"

except that you do not get the opportunity to specify a target directory.

But maybe he really wants a form of 'git checkout' instead.

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

This is only true if you cannot stop yourself from thinking about
'tar'.  What about zip, for example?

I think none of these options is relevant.

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

This slippery-slope argument is growing tiresome.


p.s. Conceded: OP set off this avalanche by disparaging the vaunted
PIPE operation.
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