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