Re: Feature request: Allow extracting revisions into directories

[Robert Clausecker <fuzxxl@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3443 bytes --]

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@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
> 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 #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]