Feature request: Allow extracting revisions into directories

Feature request: Allow extracting revisions into directories

[Robert Clausecker]

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

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: Feature request: Allow extracting revisions into directories

[Sitaram Chamarty]

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?

Re: Feature request: Allow extracting revisions into directories

[Robert Clausecker]

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


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



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: Feature request: Allow extracting revisions into directories

[Sitaram Chamarty]

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/

Re: Feature request: Allow extracting revisions into directories

[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.

Re: Feature request: Allow extracting revisions into directories

[Robert Clausecker]

[-- 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 --]

Re: Feature request: Allow extracting revisions into directories

[Junio C Hamano]

Robert Clausecker <fuzxxl@gmail.com> 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".

Re: Feature request: Allow extracting revisions into directories

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> 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 <revision> <directory>",
which may look like this, perhaps.

	#!/bin/sh
	# git export <rev> <directory>
	rev=${1?revision} dir=${2?directory}
	. $(git --exec-path)/git-sh-setup

        mkdir -p "$dir" || exit
        git archive --format=tar "$rev" |
        tar Cxf "$dir" -

Re: Feature request: Allow extracting revisions into directories

[Robert Clausecker]

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

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 <gitster@pobox.com> 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 <revision> <directory>",
> which may look like this, perhaps.
> 
> 	#!/bin/sh
> 	# git export <rev> <directory>
> 	rev=${1?revision} dir=${2?directory}
> 	. $(git --exec-path)/git-sh-setup
> 
>         mkdir -p "$dir" || exit
>         git archive --format=tar "$rev" |
>         tar Cxf "$dir" -
> 


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: Feature request: Allow extracting revisions into directories

[Jonathan Nieder]

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

Hope that helps,
Jonathan

Re: Feature request: Allow extracting revisions into directories

[Robert Clausecker]

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 <tree>
> 
> Hope that helps,
> Jonathan

Re: Feature request: Allow extracting revisions into directories

[Jonathan Nieder]

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

Re: Feature request: Allow extracting revisions into directories

[Konstantin Khomoutov]

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"

Re: Feature request: Allow extracting revisions into directories

[Michael J Gruber]

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

Re: Feature request: Allow extracting revisions into directories

[Robert Clausecker]

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

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: Feature request: Allow extracting revisions into directories

[Tomas Carnecky]

On Mon, 04 Feb 2013 13:14:05 +0100, Robert Clausecker <fuzxxl@gmail.com> 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.

Re: Feature request: Allow extracting revisions into directories

[Junio C Hamano]

Tomas Carnecky <tomas.carnecky@gmail.com> 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.

Re: Feature request: Allow extracting revisions into directories

[Sitaram Chamarty]

On Mon, Feb 4, 2013 at 10:22 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Tomas Carnecky <tomas.carnecky@gmail.com> 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'... :)

Re: Feature request: Allow extracting revisions into directories

[Andrew Ardill]

On 4 February 2013 23:14, Robert Clausecker <fuzxxl@gmail.com> 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 <tree-ish>

??

Regards,

Andrew Ardill

Re: Feature request: Allow extracting revisions into directories

[Junio C Hamano]

Andrew Ardill <andrew.ardill@gmail.com> writes:

> On 4 February 2013 23:14, Robert Clausecker <fuzxxl@gmail.com> 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 <tree-ish>
>
> ??

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
<tree-ish>.

Re: Feature request: Allow extracting revisions into directories

[Andreas Schwab]

Robert Clausecker <fuzxxl@gmail.com> 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, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Feature request: Allow extracting revisions into directories

[Thomas Koch]

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