Re: Feature request: Allow extracting revisions into directories
Robert Clausecker: > I have a server that hosts a bare git repository. This git repository > contains a branch production. Whenever somebody pushes to production a > hook automatically puts a copy of the current production branch > into /var/www/foo. I could of course use pull for that but it just does > not feels right. Why should I have a repository twice on the server? Hallo Robert, I've mostly the same requirement for a friend with a PHP webshop and started to implement my own git_export with the additional feature that it tries to reuse already exported trees as hardlink targets instead of writing the same file again. (I'm aware of the dangers of hardlinks.) https://github.com/thkoch2001/git_export_hardlinks See also the current mailing list thread: "[Request] Git export with hardlinks". Beste Grüße, Thomas Koch, http://www.koch.ro -- 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
Re: Feature request: Allow extracting revisions into directories
Robert Clausecker wrote: > That is actually a pretty interesting approach. I can use a different > index file for different deployments. How does this cooperate with bare > repositories? Aren't they supposed to have no index file at all? It should work fine in a bare repo. If you can think of a good place to sneak hints about this into the documentation (maybe as an example in git-archive(1) or a new gitenvironment(7) page), that would be very welcome. Thanks, Jonathan -- 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
Re: Feature request: Allow extracting revisions into directories
That is actually a pretty interesting approach. I can use a different index file for different deployments. How does this cooperate with bare repositories? Aren't they supposed to have no index file at all? Am Samstag, den 09.02.2013, 20:06 -0800 schrieb Jonathan Nieder: > My advice is to keep a separate index file for your exported files. > Like this: > > GIT_DIR=$(readlink -f $(git rev-parse --git-dir)) > GIT_INDEX_FILE=$GIT_DIR/index-for-deployment > export GIT_DIR GIT_INDEX_FILE > > cd $dest > git read-tree -m -u > > Hope that helps, > Jonathan -- 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
Re: Feature request: Allow extracting revisions into directories
Hi Robert, Robert Clausecker wrote: > There are two things git archive is missing that are needed in my use > case: > > First, git archive in combination with tar won't remove unneeded files. > You have to run rm -rf before manually which brings me to the next > point; git archive can't really make incremental updates. My advice is to keep a separate index file for your exported files. Like this: GIT_DIR=$(readlink -f $(git rev-parse --git-dir)) GIT_INDEX_FILE=$GIT_DIR/index-for-deployment export GIT_DIR GIT_INDEX_FILE cd $dest git read-tree -m -u Hope that helps, Jonathan -- 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
Re: Feature request: Allow extracting revisions into directories
There are two things git archive is missing that are needed in my use
case:
First, git archive in combination with tar won't remove unneeded files.
You have to run rm -rf before manually which brings me to the next
point; git archive can't really make incremental updates. Consider an
export that overwrites a tree that resembles the state of an export two
commits before and contains a lot of files. I don't like to idea of
needing to remove all files and write all of them again just to change
one or two lines.
Perhaps my real problem is not "export" but rather "Can I have multiple
work trees with multiple checked out revisions?"...
Am Samstag, den 09.02.2013, 19:45 -0800 schrieb Junio C Hamano:
> Junio C Hamano writes:
>
> > I am not Phil, but if you ask me, I think it is borderline between
> > "meh" and "no way we would give a short-and-sweet -i to something
> > like this".
>
> I think one reason it was "meh" for me is that we never did an
> equivalent of "cvs export" and "svn export", primarily because
> we had "tar-tree" (aka "archive --format=tar") first, and it was
> sufficient to pipe its outputto "tar xf -" if somebody wanted to do
> the non-existent "git export". Also "tar-tree" was more useful for
> people who wanted to eventually want to have a tarball (you can
> first "export" and then "tar cf" the resulting directory).
>
> But I think it is fine to add "git export ",
> which may look like this, perhaps.
>
> #!/bin/sh
> # git export
> rev=${1?revision} dir=${2?directory}
> . $(git --exec-path)/git-sh-setup
>
> mkdir -p "$dir" || exit
> git archive --format=tar "$rev" |
> tar Cxf "$dir" -
>
signature.asc
Description: This is a digitally signed message part
Re: Feature request: Allow extracting revisions into directories
Junio C Hamano writes:
> I am not Phil, but if you ask me, I think it is borderline between
> "meh" and "no way we would give a short-and-sweet -i to something
> like this".
I think one reason it was "meh" for me is that we never did an
equivalent of "cvs export" and "svn export", primarily because
we had "tar-tree" (aka "archive --format=tar") first, and it was
sufficient to pipe its outputto "tar xf -" if somebody wanted to do
the non-existent "git export". Also "tar-tree" was more useful for
people who wanted to eventually want to have a tarball (you can
first "export" and then "tar cf" the resulting directory).
But I think it is fine to add "git export ",
which may look like this, perhaps.
#!/bin/sh
# git export
rev=${1?revision} dir=${2?directory}
. $(git --exec-path)/git-sh-setup
mkdir -p "$dir" || exit
git archive --format=tar "$rev" |
tar Cxf "$dir" -
--
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
Re: Feature request: Allow extracting revisions into directories
Robert Clausecker writes: > 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? I am not Phil, but if you ask me, I think it is borderline between "meh" and "no way we would give a short-and-sweet -i to something like this". -- 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
Re: Feature request: Allow extracting revisions into directories
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 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. signature.asc Description: This is a digitally signed message part
Re: Feature request: Allow extracting revisions into directories
On Sun, Feb 3, 2013 at 7:42 PM, Sitaram Chamarty 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. -- 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
Re: Feature request: Allow extracting revisions into directories
On Mon, Feb 4, 2013 at 10:22 PM, Junio C Hamano wrote: > Tomas Carnecky writes: > >> That's what `git checkout` is for. And I would even argue that it's the >> better >> choice in your situation because it would delete files from /var/www/foo >> which >> you have deleted in your repo. git archive|tar wouldn't do that. > > The point about removal is an interesting one. From that /var/www > location I guess that you are discussing some webapp, but if you let > it _write_ into it, you may also have to worry about how to handle > the case where an update from the source end that comes from the > checkout and an update by the webapp collide with each other. > > You also need to maintain the .git/index file that corresponds to > what should be in /var/www/foo/ if you go that route. > > Just to be sure, I am not saying "checkout" is an inappropriate > solution to whatever problem you are trying to solve. I am just > pointing out things you need to be aware of if you take that > approach. http://sitaramc.github.com/the-list-and-irc/deploy.html is a fairly popular URL on #git, where the bot responds to "!deploy" with some text and this URL. Just sayin'... :) -- 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
Re: Feature request: Allow extracting revisions into directories
Robert Clausecker writes: > I have a server that hosts a bare git repository. This git repository > contains a branch production. Whenever somebody pushes to production a > hook automatically puts a copy of the current production branch > into /var/www/foo. I could of course use pull for that but it just does > not feels right. Why should I have a repository twice on the server? You can avoid the separate repo copy by using git new-workdir. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." -- 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
Re: Feature request: Allow extracting revisions into directories
Andrew Ardill writes: > On 4 February 2013 23:14, Robert Clausecker wrote: >> The specific workflow I am planning is this: >> >> I have a server that hosts a bare git repository. This git repository >> contains a branch production. Whenever somebody pushes to production a >> hook automatically puts a copy of the current production branch >> into /var/www/foo. I could of course use pull for that but it just does >> not feels right. Why should I have a repository twice on the server? > > Maybe I'm missing something. How does the behaviour you need differ from > >> GIT_WORKING_DIR=/var/www/foo git checkout -f > > ?? In addition to the fact that your misspellt environment variable name will not cause it to write there, you will also be overwriting the index for your working tree, which presumably you meant is a location different from the /var/www/foo, with the contents of . -- 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
Re: Feature request: Allow extracting revisions into directories
Tomas Carnecky writes: > That's what `git checkout` is for. And I would even argue that it's the better > choice in your situation because it would delete files from /var/www/foo which > you have deleted in your repo. git archive|tar wouldn't do that. The point about removal is an interesting one. From that /var/www location I guess that you are discussing some webapp, but if you let it _write_ into it, you may also have to worry about how to handle the case where an update from the source end that comes from the checkout and an update by the webapp collide with each other. You also need to maintain the .git/index file that corresponds to what should be in /var/www/foo/ if you go that route. Just to be sure, I am not saying "checkout" is an inappropriate solution to whatever problem you are trying to solve. I am just pointing out things you need to be aware of if you take that approach. -- 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
Re: Feature request: Allow extracting revisions into directories
On 4 February 2013 23:14, Robert Clausecker wrote: > The specific workflow I am planning is this: > > I have a server that hosts a bare git repository. This git repository > contains a branch production. Whenever somebody pushes to production a > hook automatically puts a copy of the current production branch > into /var/www/foo. I could of course use pull for that but it just does > not feels right. Why should I have a repository twice on the server? Maybe I'm missing something. How does the behaviour you need differ from > GIT_WORKING_DIR=/var/www/foo git checkout -f ?? Regards, Andrew Ardill -- 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
Re: Feature request: Allow extracting revisions into directories
On Mon, 04 Feb 2013 13:14:05 +0100, Robert Clausecker wrote:
> Of course that is a possibility but it does not not feel right and is
> not intuitive. Adding this feature won't cause feature creep but would
> rather add an operation that makes sense in some scenarios and reduces
> the dependencies on other commands that might not be available on other
> platforms (If you care about that).
I'd really like to see your reply to Sitaram's email regarding the many
options that tar has. Sure, just teaching git-archive the equivalent of `|tar
-x' probably isn't feature creep. But why stop there and not add some of the
other options as well? After all, some might be equally useful in a different
situation. So where do you stop? When you've completely merged tar into git?
> Also, this functionality is in full accordance with the Unix principle
> as it is a basic operation ("put tree into files") and not something
> super special.
That's what `git checkout` is for. And I would even argue that it's the better
choice in your situation because it would delete files from /var/www/foo which
you have deleted in your repo. git archive|tar wouldn't do that.
--
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
Re: Feature request: Allow extracting revisions into directories
Am Montag, den 04.02.2013, 12:18 +0100 schrieb Michael J Gruber:
> Sitaram has said much about the Unix philosophy already, and Konstantin
> gave a variant of checkout. Just two more cents:
>
> How would you copy a directory tree? I presume you wouldn't use "tar c .
> | tar -xC gothere", but what would be your worklflow?
>
> Depending on what you actually want to achieve, "git clone -b branch"
> and removing the superfluous .git-dir might be a viable option. (Beware
> the hardlinks, though.)
>
> Michael
The specific workflow I am planning is this:
I have a server that hosts a bare git repository. This git repository
contains a branch production. Whenever somebody pushes to production a
hook automatically puts a copy of the current production branch
into /var/www/foo. I could of course use pull for that but it just does
not feels right. Why should I have a repository twice on the server?
Adding an option to put the tree of an arbitrary revision into a
directory is something that improves usability as it is an operation
semantically different from tar. Saying that you can already get this
with git archive and ad-hoc unpacking is as saying: You don't need cp.
Just tar the file and untar it somewhere else.
Of course that is a possibility but it does not not feel right and is
not intuitive. Adding this feature won't cause feature creep but would
rather add an operation that makes sense in some scenarios and reduces
the dependencies on other commands that might not be available on other
platforms (If you care about that).
Also, this functionality is in full accordance with the Unix principle
as it is a basic operation ("put tree into files") and not something
super special. Also, it always feels like a hack if you do this ad-hoc
unpacking. Like "git can't do it the simple way".
Yours, Robert Clausecker
signature.asc
Description: This is a digitally signed message part
Re: Feature request: Allow extracting revisions into directories
Robert Clausecker venit, vidit, dixit 03.02.2013 15:18: > Hello! > > git currently has the archive command that allows to save an arbitrary > revision into a tar or zip file. Sometimes it is useful to not save this > revision into an archive but to directly put all files into an arbitrary > directory. Currently this seems to be not possible to archive directly; > the only way I found to do it is to run git archive and then directly > unpack the archive into a directory. > > git --git-dir REPO archive REVISION | tar x > > It would be nice to have a command or simply a switch to git archive > that allows the user to put the files of REVISION into a directory > instead of making an archive. > > Thank you very much for your help. Yours, > > Robert Clausecker Sitaram has said much about the Unix philosophy already, and Konstantin gave a variant of checkout. Just two more cents: How would you copy a directory tree? I presume you wouldn't use "tar c . | tar -xC gothere", but what would be your worklflow? Depending on what you actually want to achieve, "git clone -b branch" and removing the superfluous .git-dir might be a viable option. (Beware the hardlinks, though.) Michael -- 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
Re: Feature request: Allow extracting revisions into directories
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. 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. 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? What about computing a checksum and putting out a "sha1sums.txt" file? People do that also. How about a flag for that? Where does this end? [1]: http://www.unix.com/man-page/FreeBSD/1/tar/ -- 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
Re: Feature request: Allow extracting revisions into directories
On Sun, Feb 03, 2013 at 03:18:05PM +0100, Robert Clausecker wrote: > git currently has the archive command that allows to save an arbitrary > revision into a tar or zip file. Sometimes it is useful to not save this > revision into an archive but to directly put all files into an arbitrary > directory. Currently this seems to be not possible to archive directly; > the only way I found to do it is to run git archive and then directly > unpack the archive into a directory. > > git --git-dir REPO archive REVISION | tar x > > It would be nice to have a command or simply a switch to git archive > that allows the user to put the files of REVISION into a directory > instead of making an archive. You could use plumbing commands combined with a throwaway custom index file and a separate work tree which will receive the tree at REVISION: export GIT_WORK_TREE=/path/to/dest/directory export GIT_DIR=/path/to/repo/.git export GIT_INDEX_FILE="$GIT_WORK_TREE/.index" git read-tree REVISION git checkout-index -a rm -f "$GIT_INDEX_FILE" -- 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
Re: Feature request: Allow extracting revisions into directories
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. Yours, Robert Clausecker signature.asc Description: This is a digitally signed message part
Re: Feature request: Allow extracting revisions into directories
On 02/03/2013 07:48 PM, Robert Clausecker wrote: > Hello! > > git currently has the archive command that allows to save an arbitrary > revision into a tar or zip file. Sometimes it is useful to not save this > revision into an archive but to directly put all files into an arbitrary > directory. Currently this seems to be not possible to archive directly; > the only way I found to do it is to run git archive and then directly > unpack the archive into a directory. > > git --git-dir REPO archive REVISION | tar x > > It would be nice to have a command or simply a switch to git archive > that allows the user to put the files of REVISION into a directory > instead of making an archive. Could you help me understand why piping it to tar (actually 'tar -C /dest/dir -x') is not sufficient to achieve what you want? -- 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
Feature request: Allow extracting revisions into directories
Hello! git currently has the archive command that allows to save an arbitrary revision into a tar or zip file. Sometimes it is useful to not save this revision into an archive but to directly put all files into an arbitrary directory. Currently this seems to be not possible to archive directly; the only way I found to do it is to run git archive and then directly unpack the archive into a directory. git --git-dir REPO archive REVISION | tar x It would be nice to have a command or simply a switch to git archive that allows the user to put the files of REVISION into a directory instead of making an archive. Thank you very much for your help. Yours, Robert Clausecker signature.asc Description: This is a digitally signed message part
