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