After thinking a while about how to solve the problems I have, I consider the following things as a solution to my problem. Add an option --isolated, -i to git checkout: Check out a branch / tag / revision but do not touch the index. This could be used together with --work-tree to check out a branch into an arbitrary directory. Also, it satisfies all 4 criteria from [1] and therefore is perfect for deployment from a bare repository. What do you think about this feature request? Yours, Robert Clausecker [1]: http://sitaramc.github.com/the-list-and-irc/deploy.html Am Dienstag, den 05.02.2013, 10:11 -0500 schrieb Phil Hord: > On Sun, Feb 3, 2013 at 7:42 PM, Sitaram Chamarty <sitaramc@xxxxxxxxx> 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 > 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.
Attachment:
signature.asc
Description: This is a digitally signed message part