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
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 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 [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
Robert Clausecker fuz...@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. -- 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
Junio C Hamano gits...@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 -
--
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 gits...@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 -
signature.asc
Description: This is a digitally signed message part
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 tree 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
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 -- 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
On Mon, Feb 4, 2013 at 10:22 PM, Junio C Hamano gits...@pobox.com wrote: Tomas Carnecky tomas.carne...@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'... :) -- 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 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 Mon, 04 Feb 2013 13:14:05 +0100, Robert Clausecker fuz...@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. -- 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 fuz...@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 -- 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 andrew.ard...@gmail.com writes: On 4 February 2013 23:14, Robert Clausecker fuz...@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. -- 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 fuz...@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, 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
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
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
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 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
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
