{"thread":{"id":"32816","subject":"Feature request: Allow extracting revisions into directories","startedAt":"2013-02-03T14:18:05Z","lastAt":"2013-02-10T12:16:00Z","messageCount":22,"participants":["Robert Clausecker","Sitaram Chamarty","Konstantin Khomoutov","Michael J Gruber","Tomas Carnecky","Andrew Ardill","Junio C Hamano","Andreas Schwab","Phil Hord","Jonathan Nieder","Thomas Koch"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"208542","messageId":"1359901085.24730.11.camel@t520","threadId":"32816","inReplyTo":null,"subject":"Feature request: Allow extracting revisions into directories","fromName":"Robert Clausecker","fromEmail":"fuzxxl@gmail.com","sentAt":"2013-02-03T14:18:05Z","receivedAt":"2013-02-03T14:18:05Z","isPatch":false,"sender":{"key":"fuzxxl@gmail.com","avatar":"https://gravatar.com/avatar/4e7ce39f11fdb27adbc2f3ed63d580cd0f69958a94ef04381f4aad53ed083909?d=mp&s=160"},"body":"Hello!\n\ngit currently has the archive command that allows to save an arbitrary\nrevision into a tar or zip file. Sometimes it is useful to not save this\nrevision into an archive but to directly put all files into an arbitrary\ndirectory. Currently this seems to be not possible to archive directly;\nthe only way I found to do it is to run git archive and then directly\nunpack the archive into a directory.\n\n    git --git-dir REPO archive REVISION | tar x\n\nIt would be nice to have a command or simply a switch to git archive\nthat allows the user to put the files of REVISION into a directory\ninstead of making an archive.\n\nThank you very much for your help. Yours,\n\nRobert Clausecker\n"},{"id":"208549","messageId":"510E8F82.9050306@gmail.com","threadId":"32816","inReplyTo":"1359901085.24730.11.camel@t520","subject":"Re: Feature request: Allow extracting revisions into directories","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2013-02-03T16:25:38Z","receivedAt":"2013-02-03T16:25:38Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"On 02/03/2013 07:48 PM, Robert Clausecker wrote:\n> Hello!\n> \n> git currently has the archive command that allows to save an arbitrary\n> revision into a tar or zip file. Sometimes it is useful to not save this\n> revision into an archive but to directly put all files into an arbitrary\n> directory. Currently this seems to be not possible to archive directly;\n> the only way I found to do it is to run git archive and then directly\n> unpack the archive into a directory.\n> \n>     git --git-dir REPO archive REVISION | tar x\n> \n> It would be nice to have a command or simply a switch to git archive\n> that allows the user to put the files of REVISION into a directory\n> instead of making an archive.\n\nCould you help me understand why piping it to tar (actually 'tar -C\n/dest/dir -x') is not sufficient to achieve what you want?\n"},{"id":"208552","messageId":"1359915086.24730.19.camel@t520","threadId":"32816","inReplyTo":"510E8F82.9050306@gmail.com","subject":"Re: Feature request: Allow extracting revisions into directories","fromName":"Robert Clausecker","fromEmail":"fuzxxl@gmail.com","sentAt":"2013-02-03T18:11:26Z","receivedAt":"2013-02-03T18:11:26Z","isPatch":false,"sender":{"key":"fuzxxl@gmail.com","avatar":"https://gravatar.com/avatar/4e7ce39f11fdb27adbc2f3ed63d580cd0f69958a94ef04381f4aad53ed083909?d=mp&s=160"},"body":"\nAm Sonntag, den 03.02.2013, 21:55 +0530 schrieb Sitaram Chamarty:\n> Could you help me understand why piping it to tar (actually 'tar -C\n> /dest/dir -x') is not sufficient to achieve what you want?\n\nPiping the output of git archive into tar is of course a possible\nsolution; I just don't like the fact that you need to pipe the output\ninto a separate program to do something that should be possible with a\nsimple switch and not an extra command. It feels unintuitive and like a\nworkaround to make an archive just to unpack it on-the-fly. Also, adding\nsuch a command (or at least documenting the way to do this using a pipe\nto tar somewhere in the man pages) is a small and simple change that\nimproves usability.\n\nYours, Robert Clausecker\n\n\n"},{"id":"208575","messageId":"20130203232651.GV5210@localhost.localdomain","threadId":"32816","inReplyTo":"1359901085.24730.11.camel@t520","subject":"Re: Feature request: Allow extracting revisions into directories","fromName":"Konstantin Khomoutov","fromEmail":"kostix+git@007spb.ru","sentAt":"2013-02-03T23:26:51Z","receivedAt":"2013-02-03T23:26:51Z","isPatch":false,"sender":{"key":"kostix+git@007spb.ru","avatar":null},"body":"On Sun, Feb 03, 2013 at 03:18:05PM +0100, Robert Clausecker wrote:\n\n> git currently has the archive command that allows to save an arbitrary\n> revision into a tar or zip file. Sometimes it is useful to not save this\n> revision into an archive but to directly put all files into an arbitrary\n> directory. Currently this seems to be not possible to archive directly;\n> the only way I found to do it is to run git archive and then directly\n> unpack the archive into a directory.\n> \n>     git --git-dir REPO archive REVISION | tar x\n> \n> It would be nice to have a command or simply a switch to git archive\n> that allows the user to put the files of REVISION into a directory\n> instead of making an archive.\n\nYou could use plumbing commands combined with a throwaway custom index\nfile and a separate work tree which will receive the tree at REVISION:\n\nexport GIT_WORK_TREE=/path/to/dest/directory\nexport GIT_DIR=/path/to/repo/.git\nexport GIT_INDEX_FILE=\"$GIT_WORK_TREE/.index\"\ngit read-tree REVISION\ngit checkout-index -a\nrm -f \"$GIT_INDEX_FILE\"\n"},{"id":"208578","messageId":"510F03FC.6080501@gmail.com","threadId":"32816","inReplyTo":"1359915086.24730.19.camel@t520","subject":"Re: Feature request: Allow extracting revisions into directories","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2013-02-04T00:42:36Z","receivedAt":"2013-02-04T00:42:36Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"On 02/03/2013 11:41 PM, Robert Clausecker wrote:\n> \n> Am Sonntag, den 03.02.2013, 21:55 +0530 schrieb Sitaram Chamarty:\n>> Could you help me understand why piping it to tar (actually 'tar -C\n>> /dest/dir -x') is not sufficient to achieve what you want?\n> \n> Piping the output of git archive into tar is of course a possible\n> solution; I just don't like the fact that you need to pipe the output\n> into a separate program to do something that should be possible with a\n> simple switch and not an extra command. It feels unintuitive and like a\n> workaround to make an archive just to unpack it on-the-fly. Also, adding\n> such a command (or at least documenting the way to do this using a pipe\n> to tar somewhere in the man pages) is a small and simple change that\n> improves usability.\n\nI realise it appears to be the fashion these days to get away from the\nUnix philosophy of having different tools do different things and\ncombining them as needed.\n\nIgnoring the option-heavy GNU, and looking at the more traditional BSD\ntar manpage [1], I notice the following flags that could still be\npotentially needed by someone running 'git archive': '-t' (instead of\n'-x'), '-C dir', '--exclude/include', '-k', '-m', '--numeric-owner', -o,\n-P, -p, -q, -s, -T, -U, -v, -w, and -X.\n\nAnd I'm ignoring the esoteric ones like \"--chroot\" and \"-S\" (sparse mode).\n\nHow many of these options would you like included in git?  And if you\nsay \"I don't need any of those; I just need '-x'\", that's not relevant.\n Someone else may need any or all of those flags, and if you accept \"-x\"\nyou have to accept some of the others too.\n\nAlso, I often want to deploy to a different host, and I might do that\nlike so:\n\n    git archive ... | ssh host tar -C /deploy/dir -x\n\nWhy not put that ssh functionality into git also?\n\nWhat about computing a checksum and putting out a \"sha1sums.txt\" file?\nPeople do that also.  How about a flag for that?\n\nWhere does this end?\n\n[1]: http://www.unix.com/man-page/FreeBSD/1/tar/\n"},{"id":"208602","messageId":"510F9907.7010107@drmicha.warpmail.net","threadId":"32816","inReplyTo":"1359901085.24730.11.camel@t520","subject":"Re: Feature request: Allow extracting revisions into directories","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2013-02-04T11:18:31Z","receivedAt":"2013-02-04T11:18:31Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Robert Clausecker venit, vidit, dixit 03.02.2013 15:18:\n> Hello!\n> \n> git currently has the archive command that allows to save an arbitrary\n> revision into a tar or zip file. Sometimes it is useful to not save this\n> revision into an archive but to directly put all files into an arbitrary\n> directory. Currently this seems to be not possible to archive directly;\n> the only way I found to do it is to run git archive and then directly\n> unpack the archive into a directory.\n> \n>     git --git-dir REPO archive REVISION | tar x\n> \n> It would be nice to have a command or simply a switch to git archive\n> that allows the user to put the files of REVISION into a directory\n> instead of making an archive.\n> \n> Thank you very much for your help. Yours,\n> \n> Robert Clausecker\n\nSitaram has said much about the Unix philosophy already, and Konstantin\ngave a variant of checkout. Just two more cents:\n\nHow would you copy a directory tree? I presume you wouldn't use \"tar c .\n| tar -xC gothere\", but what would be your worklflow?\n\nDepending on what you actually want to achieve, \"git clone -b branch\"\nand removing the superfluous .git-dir might be a viable option. (Beware\nthe hardlinks, though.)\n\nMichael\n"},{"id":"208603","messageId":"1359980045.24730.32.camel@t520","threadId":"32816","inReplyTo":"510F9907.7010107@drmicha.warpmail.net","subject":"Re: Feature request: Allow extracting revisions into directories","fromName":"Robert Clausecker","fromEmail":"fuzxxl@gmail.com","sentAt":"2013-02-04T12:14:05Z","receivedAt":"2013-02-04T12:14:05Z","isPatch":false,"sender":{"key":"fuzxxl@gmail.com","avatar":"https://gravatar.com/avatar/4e7ce39f11fdb27adbc2f3ed63d580cd0f69958a94ef04381f4aad53ed083909?d=mp&s=160"},"body":"Am Montag, den 04.02.2013, 12:18 +0100 schrieb Michael J Gruber:\n> Sitaram has said much about the Unix philosophy already, and Konstantin\n> gave a variant of checkout. Just two more cents:\n> \n> How would you copy a directory tree? I presume you wouldn't use \"tar c .\n> | tar -xC gothere\", but what would be your worklflow?\n> \n> Depending on what you actually want to achieve, \"git clone -b branch\"\n> and removing the superfluous .git-dir might be a viable option. (Beware\n> the hardlinks, though.)\n>\n> Michael\n\nThe specific workflow I am planning is this:\n\nI have a server that hosts a bare git repository. This git repository\ncontains a branch production. Whenever somebody pushes to production a\nhook automatically puts a copy of the current production branch\ninto /var/www/foo. I could of course use pull for that but it just does\nnot feels right. Why should I have a repository twice on the server? \n\nAdding an option to put the tree of an arbitrary revision into a\ndirectory is something that improves usability as it is an operation\nsemantically different from tar. Saying that you can already get this\nwith git archive and ad-hoc unpacking is as saying: You don't need cp.\nJust tar the file and untar it somewhere else.\n\nOf course that is a possibility but it does not not feel right and is\nnot intuitive. Adding this feature won't cause feature creep but would\nrather add an operation that makes sense in some scenarios and reduces\nthe dependencies on other commands that might not be available on other\nplatforms (If you care about that).\n\nAlso, this functionality is in full accordance with the Unix principle\nas it is a basic operation (\"put tree into files\") and not something\nsuper special. Also, it always feels like a hack if you do this ad-hoc\nunpacking. Like \"git can't do it the simple way\".\n\nYours, Robert Clausecker\n"},{"id":"208604","messageId":"1359982065-ner-9588@calvin","threadId":"32816","inReplyTo":"1359980045.24730.32.camel@t520","subject":"Re: Feature request: Allow extracting revisions into directories","fromName":"Tomas Carnecky","fromEmail":"tomas.carnecky@gmail.com","sentAt":"2013-02-04T12:47:45Z","receivedAt":"2013-02-04T12:47:45Z","isPatch":false,"sender":{"key":"tomas.carnecky@gmail.com","avatar":null},"body":"On Mon, 04 Feb 2013 13:14:05 +0100, Robert Clausecker <fuzxxl@gmail.com> wrote:\n> Of course that is a possibility but it does not not feel right and is\n> not intuitive. Adding this feature won't cause feature creep but would\n> rather add an operation that makes sense in some scenarios and reduces\n> the dependencies on other commands that might not be available on other\n> platforms (If you care about that).\n\nI'd really like to see your reply to Sitaram's email regarding the many\noptions that tar has. Sure, just teaching git-archive the equivalent of `|tar\n-x' probably isn't feature creep. But why stop there and not add some of the\nother options as well? After all, some might be equally useful in a different\nsituation. So where do you stop? When you've completely merged tar into git?\n\n> Also, this functionality is in full accordance with the Unix principle\n> as it is a basic operation (\"put tree into files\") and not something\n> super special.\n\nThat's what `git checkout` is for. And I would even argue that it's the better\nchoice in your situation because it would delete files from /var/www/foo which\nyou have deleted in your repo. git archive|tar wouldn't do that.\n"},{"id":"208607","messageId":"CAH5451mp6fRU25LWE+8gk1h6Mz=y_XQHaU-iE0k4=bP0RfzLAA@mail.gmail.com","threadId":"32816","inReplyTo":"1359980045.24730.32.camel@t520","subject":"Re: Feature request: Allow extracting revisions into directories","fromName":"Andrew Ardill","fromEmail":"andrew.ardill@gmail.com","sentAt":"2013-02-04T12:58:39Z","receivedAt":"2013-02-04T12:58:39Z","isPatch":false,"sender":{"key":"andrew.ardill@gmail.com","avatar":"https://gravatar.com/avatar/da14cb7c091dd44dc6c63a4d3361b149acaf25226dc78eb4131a17b93d9b0993?d=mp&s=160"},"body":"On 4 February 2013 23:14, Robert Clausecker <fuzxxl@gmail.com> wrote:\n> The specific workflow I am planning is this:\n>\n> I have a server that hosts a bare git repository. This git repository\n> contains a branch production. Whenever somebody pushes to production a\n> hook automatically puts a copy of the current production branch\n> into /var/www/foo. I could of course use pull for that but it just does\n> not feels right. Why should I have a repository twice on the server?\n\nMaybe I'm missing something. How does the behaviour you need differ from\n\n> GIT_WORKING_DIR=/var/www/foo git checkout -f <tree-ish>\n\n??\n\nRegards,\n\nAndrew Ardill\n"},{"id":"208621","messageId":"7v7gmo3tte.fsf@alter.siamese.dyndns.org","threadId":"32816","inReplyTo":"1359982065-ner-9588@calvin","subject":"Re: Feature request: Allow extracting revisions into directories","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-02-04T16:52:29Z","receivedAt":"2013-02-04T16:52:29Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Tomas Carnecky <tomas.carnecky@gmail.com> writes:\n\n> That's what `git checkout` is for. And I would even argue that it's the better\n> choice in your situation because it would delete files from /var/www/foo which\n> you have deleted in your repo. git archive|tar wouldn't do that.\n\nThe point about removal is an interesting one.  From that /var/www\nlocation I guess that you are discussing some webapp, but if you let\nit _write_ into it, you may also have to worry about how to handle\nthe case where an update from the source end that comes from the\ncheckout and an update by the webapp collide with each other.\n\nYou also need to maintain the .git/index file that corresponds to\nwhat should be in /var/www/foo/ if you go that route.\n\nJust to be sure, I am not saying \"checkout\" is an inappropriate\nsolution to whatever problem you are trying to solve. I am just\npointing out things you need to be aware of if you take that\napproach.\n"},{"id":"208622","messageId":"7v38xc3toq.fsf@alter.siamese.dyndns.org","threadId":"32816","inReplyTo":"CAH5451mp6fRU25LWE+8gk1h6Mz=y_XQHaU-iE0k4=bP0RfzLAA@mail.gmail.com","subject":"Re: Feature request: Allow extracting revisions into directories","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-02-04T16:55:17Z","receivedAt":"2013-02-04T16:55:17Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andrew Ardill <andrew.ardill@gmail.com> writes:\n\n> On 4 February 2013 23:14, Robert Clausecker <fuzxxl@gmail.com> wrote:\n>> The specific workflow I am planning is this:\n>>\n>> I have a server that hosts a bare git repository. This git repository\n>> contains a branch production. Whenever somebody pushes to production a\n>> hook automatically puts a copy of the current production branch\n>> into /var/www/foo. I could of course use pull for that but it just does\n>> not feels right. Why should I have a repository twice on the server?\n>\n> Maybe I'm missing something. How does the behaviour you need differ from\n>\n>> GIT_WORKING_DIR=/var/www/foo git checkout -f <tree-ish>\n>\n> ??\n\nIn addition to the fact that your misspellt environment variable\nname will not cause it to write there, you will also be overwriting\nthe index for your working tree, which presumably you meant is a\nlocation different from the /var/www/foo, with the contents of\n<tree-ish>.\n"},{"id":"208631","messageId":"m2ip689by1.fsf@igel.home","threadId":"32816","inReplyTo":"1359980045.24730.32.camel@t520","subject":"Re: Feature request: Allow extracting revisions into directories","fromName":"Andreas Schwab","fromEmail":"schwab@linux-m68k.org","sentAt":"2013-02-04T18:21:58Z","receivedAt":"2013-02-04T18:21:58Z","isPatch":false,"sender":{"key":"schwab@linux-m68k.org","avatar":"https://avatars.githubusercontent.com/u/2175493?v=4"},"body":"Robert Clausecker <fuzxxl@gmail.com> writes:\n\n> I have a server that hosts a bare git repository. This git repository\n> contains a branch production. Whenever somebody pushes to production a\n> hook automatically puts a copy of the current production branch\n> into /var/www/foo. I could of course use pull for that but it just does\n> not feels right. Why should I have a repository twice on the server? \n\nYou can avoid the separate repo copy by using git new-workdir.\n\nAndreas.\n\n-- \nAndreas Schwab, schwab@linux-m68k.org\nGPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5\n\"And now for something completely different.\"\n"},{"id":"208695","messageId":"CAMK1S_j_7MjuLoER8CGXhnEasu2XANcB9zkV7k=G_TUYXaw+Tg@mail.gmail.com","threadId":"32816","inReplyTo":"7v7gmo3tte.fsf@alter.siamese.dyndns.org","subject":"Re: Feature request: Allow extracting revisions into directories","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2013-02-05T08:55:55Z","receivedAt":"2013-02-05T08:55:55Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"On Mon, Feb 4, 2013 at 10:22 PM, Junio C Hamano <gitster@pobox.com> wrote:\n> Tomas Carnecky <tomas.carnecky@gmail.com> writes:\n>\n>> That's what `git checkout` is for. And I would even argue that it's the better\n>> choice in your situation because it would delete files from /var/www/foo which\n>> you have deleted in your repo. git archive|tar wouldn't do that.\n>\n> The point about removal is an interesting one.  From that /var/www\n> location I guess that you are discussing some webapp, but if you let\n> it _write_ into it, you may also have to worry about how to handle\n> the case where an update from the source end that comes from the\n> checkout and an update by the webapp collide with each other.\n>\n> You also need to maintain the .git/index file that corresponds to\n> what should be in /var/www/foo/ if you go that route.\n>\n> Just to be sure, I am not saying \"checkout\" is an inappropriate\n> solution to whatever problem you are trying to solve. I am just\n> pointing out things you need to be aware of if you take that\n> approach.\n\nhttp://sitaramc.github.com/the-list-and-irc/deploy.html is a fairly\npopular URL on #git, where the bot responds to \"!deploy\" with some\ntext and this URL.\n\nJust sayin'... :)\n"},{"id":"208728","messageId":"CABURp0rMk-W8VMRhXoR9YYQSwjWTfPbXz5mhPX3-HKsBSu5_mw@mail.gmail.com","threadId":"32816","inReplyTo":"510F03FC.6080501@gmail.com","subject":"Re: Feature request: Allow extracting revisions into directories","fromName":"Phil Hord","fromEmail":"phil.hord@gmail.com","sentAt":"2013-02-05T15:11:53Z","receivedAt":"2013-02-05T15:11:53Z","isPatch":false,"sender":{"key":"phil.hord@gmail.com","avatar":"https://avatars.githubusercontent.com/u/123908?v=4"},"body":"On Sun, Feb 3, 2013 at 7:42 PM, Sitaram Chamarty <sitaramc@gmail.com> wrote:\n> On 02/03/2013 11:41 PM, Robert Clausecker wrote:\n>>\n>> Am Sonntag, den 03.02.2013, 21:55 +0530 schrieb Sitaram Chamarty:\n>>> Could you help me understand why piping it to tar (actually 'tar -C\n>>> /dest/dir -x') is not sufficient to achieve what you want?\n>>\n>> Piping the output of git archive into tar is of course a possible\n>> solution; I just don't like the fact that you need to pipe the output\n>> into a separate program to do something that should be possible with a\n>> simple switch and not an extra command. It feels unintuitive and like a\n>> workaround to make an archive just to unpack it on-the-fly. Also, adding\n>> such a command (or at least documenting the way to do this using a pipe\n>> to tar somewhere in the man pages) is a small and simple change that\n>> improves usability.\n>\n> I realise it appears to be the fashion these days to get away from the\n> Unix philosophy of having different tools do different things and\n> combining them as needed.\n>\n> Ignoring the option-heavy GNU, and looking at the more traditional BSD\n> tar manpage [1], I notice the following flags that could still be\n> potentially needed by someone running 'git archive': '-t' (instead of\n> '-x'), '-C dir', '--exclude/include', '-k', '-m', '--numeric-owner', -o,\n> -P, -p, -q, -s, -T, -U, -v, -w, and -X.\n\nOP did not ask about tar so I do not see why any of these tar options\nare relevant.  It seems like what he really wants is 'git archive\n--format=native' , maybe.   You can almost create this option by\nsaying\n\n   git config tar.native.command \"tar -x\"\n\nexcept that you do not get the opportunity to specify a target directory.\n\nBut maybe he really wants a form of 'git checkout' instead.\n\n\n> And I'm ignoring the esoteric ones like \"--chroot\" and \"-S\" (sparse mode).\n>\n> How many of these options would you like included in git?  And if you\n> say \"I don't need any of those; I just need '-x'\", that's not relevant.\n>  Someone else may need any or all of those flags, and if you accept \"-x\"\n> you have to accept some of the others too.\n\nThis is only true if you cannot stop yourself from thinking about\n'tar'.  What about zip, for example?\n\nI think none of these options is relevant.\n\n\n> Also, I often want to deploy to a different host, and I might do that\n> like so:\n>\n>     git archive ... | ssh host tar -C /deploy/dir -x\n>\n> Why not put that ssh functionality into git also?\n\nThis slippery-slope argument is growing tiresome.\n\nPhil\n\np.s. Conceded: OP set off this avalanche by disparaging the vaunted\nPIPE operation.\n"},{"id":"209084","messageId":"1360425499.3369.10.camel@t520","threadId":"32816","inReplyTo":"CABURp0rMk-W8VMRhXoR9YYQSwjWTfPbXz5mhPX3-HKsBSu5_mw@mail.gmail.com","subject":"Re: Feature request: Allow extracting revisions into directories","fromName":"Robert Clausecker","fromEmail":"fuzxxl@gmail.com","sentAt":"2013-02-09T15:58:19Z","receivedAt":"2013-02-09T15:58:19Z","isPatch":false,"sender":{"key":"fuzxxl@gmail.com","avatar":"https://gravatar.com/avatar/4e7ce39f11fdb27adbc2f3ed63d580cd0f69958a94ef04381f4aad53ed083909?d=mp&s=160"},"body":"After thinking a while about how to solve the problems I have, I\nconsider the following things as a solution to my problem.\n\nAdd an option --isolated, -i to git checkout: Check out a branch / tag /\nrevision but do not touch the index. This could be used together with\n--work-tree to check out a branch into an arbitrary directory. Also, it\nsatisfies all 4 criteria from [1] and therefore is perfect for\ndeployment from a bare repository.\n\nWhat do you think about this feature request?\n\nYours, Robert Clausecker\n\n[1]: http://sitaramc.github.com/the-list-and-irc/deploy.html\n\nAm Dienstag, den 05.02.2013, 10:11 -0500 schrieb Phil Hord:\n> On Sun, Feb 3, 2013 at 7:42 PM, Sitaram Chamarty <sitaramc@gmail.com> wrote:\n> > On 02/03/2013 11:41 PM, Robert Clausecker wrote:\n> >>\n> >> Am Sonntag, den 03.02.2013, 21:55 +0530 schrieb Sitaram Chamarty:\n> >>> Could you help me understand why piping it to tar (actually 'tar -C\n> >>> /dest/dir -x') is not sufficient to achieve what you want?\n> >>\n> >> Piping the output of git archive into tar is of course a possible\n> >> solution; I just don't like the fact that you need to pipe the output\n> >> into a separate program to do something that should be possible with a\n> >> simple switch and not an extra command. It feels unintuitive and like a\n> >> workaround to make an archive just to unpack it on-the-fly. Also, adding\n> >> such a command (or at least documenting the way to do this using a pipe\n> >> to tar somewhere in the man pages) is a small and simple change that\n> >> improves usability.\n> >\n> > I realise it appears to be the fashion these days to get away from the\n> > Unix philosophy of having different tools do different things and\n> > combining them as needed.\n> >\n> > Ignoring the option-heavy GNU, and looking at the more traditional BSD\n> > tar manpage [1], I notice the following flags that could still be\n> > potentially needed by someone running 'git archive': '-t' (instead of\n> > '-x'), '-C dir', '--exclude/include', '-k', '-m', '--numeric-owner', -o,\n> > -P, -p, -q, -s, -T, -U, -v, -w, and -X.\n> \n> OP did not ask about tar so I do not see why any of these tar options\n> are relevant.  It seems like what he really wants is 'git archive\n> --format=native' , maybe.   You can almost create this option by\n> saying\n> \n>    git config tar.native.command \"tar -x\"\n> \n> except that you do not get the opportunity to specify a target directory.\n> \n> But maybe he really wants a form of 'git checkout' instead.\n> \n> \n> > And I'm ignoring the esoteric ones like \"--chroot\" and \"-S\" (sparse mode).\n> >\n> > How many of these options would you like included in git?  And if you\n> > say \"I don't need any of those; I just need '-x'\", that's not relevant.\n> >  Someone else may need any or all of those flags, and if you accept \"-x\"\n> > you have to accept some of the others too.\n> \n> This is only true if you cannot stop yourself from thinking about\n> 'tar'.  What about zip, for example?\n> \n> I think none of these options is relevant.\n> \n> \n> > Also, I often want to deploy to a different host, and I might do that\n> > like so:\n> >\n> >     git archive ... | ssh host tar -C /deploy/dir -x\n> >\n> > Why not put that ssh functionality into git also?\n> \n> This slippery-slope argument is growing tiresome.\n> \n> Phil\n> \n> p.s. Conceded: OP set off this avalanche by disparaging the vaunted\n> PIPE operation.\n\n"},{"id":"209099","messageId":"7vehgpum7n.fsf@alter.siamese.dyndns.org","threadId":"32816","inReplyTo":"1360425499.3369.10.camel@t520","subject":"Re: Feature request: Allow extracting revisions into directories","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-02-09T23:00:28Z","receivedAt":"2013-02-09T23:00:28Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Robert Clausecker <fuzxxl@gmail.com> writes:\n\n> After thinking a while about how to solve the problems I have, I\n> consider the following things as a solution to my problem.\n>\n> Add an option --isolated, -i to git checkout: Check out a branch / tag /\n> revision but do not touch the index. This could be used together with\n> --work-tree to check out a branch into an arbitrary directory. Also, it\n> satisfies all 4 criteria from [1] and therefore is perfect for\n> deployment from a bare repository.\n>\n> What do you think about this feature request?\n\nI am not Phil, but if you ask me, I think it is borderline between\n\"meh\" and \"no way we would give a short-and-sweet -i to something\nlike this\".\n"},{"id":"209109","messageId":"7vpq08u903.fsf@alter.siamese.dyndns.org","threadId":"32816","inReplyTo":"7vehgpum7n.fsf@alter.siamese.dyndns.org","subject":"Re: Feature request: Allow extracting revisions into directories","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-02-10T03:45:48Z","receivedAt":"2013-02-10T03:45:48Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> I am not Phil, but if you ask me, I think it is borderline between\n> \"meh\" and \"no way we would give a short-and-sweet -i to something\n> like this\".\n\nI think one reason it was \"meh\" for me is that we never did an\nequivalent of \"cvs export\" and \"svn export\", primarily because\nwe had \"tar-tree\" (aka \"archive --format=tar\") first, and it was\nsufficient to pipe its outputto \"tar xf -\" if somebody wanted to do\nthe non-existent \"git export\".  Also \"tar-tree\" was more useful for\npeople who wanted to eventually want to have a tarball (you can\nfirst \"export\" and then \"tar cf\" the resulting directory).\n\nBut I think it is fine to add \"git export <revision> <directory>\",\nwhich may look like this, perhaps.\n\n\t#!/bin/sh\n\t# git export <rev> <directory>\n\trev=${1?revision} dir=${2?directory}\n\t. $(git --exec-path)/git-sh-setup\n\n        mkdir -p \"$dir\" || exit\n        git archive --format=tar \"$rev\" |\n        tar Cxf \"$dir\" -\n"},{"id":"209110","messageId":"1360468628.6610.5.camel@t520","threadId":"32816","inReplyTo":"7vpq08u903.fsf@alter.siamese.dyndns.org","subject":"Re: Feature request: Allow extracting revisions into directories","fromName":"Robert Clausecker","fromEmail":"fuzxxl@gmail.com","sentAt":"2013-02-10T03:57:08Z","receivedAt":"2013-02-10T03:57:08Z","isPatch":false,"sender":{"key":"fuzxxl@gmail.com","avatar":"https://gravatar.com/avatar/4e7ce39f11fdb27adbc2f3ed63d580cd0f69958a94ef04381f4aad53ed083909?d=mp&s=160"},"body":"There are two things git archive is missing that are needed in my use\ncase:\n\nFirst, git archive in combination with tar won't remove unneeded files.\nYou have to run rm -rf before manually which brings me to the next\npoint; git archive can't really make incremental updates. Consider an\nexport that overwrites a tree that resembles the state of an export two\ncommits before and contains a lot of files. I don't like to idea of\nneeding to remove all files and write all of them again just to change\none or two lines.\n\nPerhaps my real problem is not \"export\" but rather \"Can I have multiple\nwork trees with multiple checked out revisions?\"...\n\nAm Samstag, den 09.02.2013, 19:45 -0800 schrieb Junio C Hamano:\n> Junio C Hamano <gitster@pobox.com> writes:\n> \n> > I am not Phil, but if you ask me, I think it is borderline between\n> > \"meh\" and \"no way we would give a short-and-sweet -i to something\n> > like this\".\n> \n> I think one reason it was \"meh\" for me is that we never did an\n> equivalent of \"cvs export\" and \"svn export\", primarily because\n> we had \"tar-tree\" (aka \"archive --format=tar\") first, and it was\n> sufficient to pipe its outputto \"tar xf -\" if somebody wanted to do\n> the non-existent \"git export\".  Also \"tar-tree\" was more useful for\n> people who wanted to eventually want to have a tarball (you can\n> first \"export\" and then \"tar cf\" the resulting directory).\n> \n> But I think it is fine to add \"git export <revision> <directory>\",\n> which may look like this, perhaps.\n> \n> \t#!/bin/sh\n> \t# git export <rev> <directory>\n> \trev=${1?revision} dir=${2?directory}\n> \t. $(git --exec-path)/git-sh-setup\n> \n>         mkdir -p \"$dir\" || exit\n>         git archive --format=tar \"$rev\" |\n>         tar Cxf \"$dir\" -\n> \n\n"},{"id":"209111","messageId":"20130210040621.GA8584@elie.Belkin","threadId":"32816","inReplyTo":"1360468628.6610.5.camel@t520","subject":"Re: Feature request: Allow extracting revisions into directories","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-02-10T04:06:21Z","receivedAt":"2013-02-10T04:06:21Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi Robert,\n\nRobert Clausecker wrote:\n\n> There are two things git archive is missing that are needed in my use\n> case:\n>\n> First, git archive in combination with tar won't remove unneeded files.\n> You have to run rm -rf before manually which brings me to the next\n> point; git archive can't really make incremental updates.\n\nMy advice is to keep a separate index file for your exported files.\nLike this:\n\n\tGIT_DIR=$(readlink -f $(git rev-parse --git-dir))\n\tGIT_INDEX_FILE=$GIT_DIR/index-for-deployment\n\texport GIT_DIR GIT_INDEX_FILE\n\n\tcd $dest\n\tgit read-tree -m -u <tree>\n\nHope that helps,\nJonathan\n"},{"id":"209112","messageId":"1360469440.6610.8.camel@t520","threadId":"32816","inReplyTo":"20130210040621.GA8584@elie.Belkin","subject":"Re: Feature request: Allow extracting revisions into directories","fromName":"Robert Clausecker","fromEmail":"fuzxxl@gmail.com","sentAt":"2013-02-10T04:10:40Z","receivedAt":"2013-02-10T04:10:40Z","isPatch":false,"sender":{"key":"fuzxxl@gmail.com","avatar":"https://gravatar.com/avatar/4e7ce39f11fdb27adbc2f3ed63d580cd0f69958a94ef04381f4aad53ed083909?d=mp&s=160"},"body":"That is actually a pretty interesting approach. I can use a different\nindex file for different deployments. How does this cooperate with bare\nrepositories? Aren't they supposed to have no index file at all?\n\nAm Samstag, den 09.02.2013, 20:06 -0800 schrieb Jonathan Nieder:\n> My advice is to keep a separate index file for your exported files.\n> Like this:\n> \n> \tGIT_DIR=$(readlink -f $(git rev-parse --git-dir))\n> \tGIT_INDEX_FILE=$GIT_DIR/index-for-deployment\n> \texport GIT_DIR GIT_INDEX_FILE\n> \n> \tcd $dest\n> \tgit read-tree -m -u <tree>\n> \n> Hope that helps,\n> Jonathan\n"},{"id":"209113","messageId":"20130210041912.GB8584@elie.Belkin","threadId":"32816","inReplyTo":"1360469440.6610.8.camel@t520","subject":"Re: Feature request: Allow extracting revisions into directories","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-02-10T04:19:12Z","receivedAt":"2013-02-10T04:19:12Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Robert Clausecker wrote:\n\n> That is actually a pretty interesting approach. I can use a different\n> index file for different deployments. How does this cooperate with bare\n> repositories? Aren't they supposed to have no index file at all?\n\nIt should work fine in a bare repo.\n\nIf you can think of a good place to sneak hints about this into the\ndocumentation (maybe as an example in git-archive(1) or a new\ngitenvironment(7) page), that would be very welcome.\n\nThanks,\nJonathan\n"},{"id":"209119","messageId":"201302101316.02549.thomas@koch.ro","threadId":"32816","inReplyTo":"1359980045.24730.32.camel@t520","subject":"Re: Feature request: Allow extracting revisions into directories","fromName":"Thomas Koch","fromEmail":"thomas@koch.ro","sentAt":"2013-02-10T12:16:00Z","receivedAt":"2013-02-10T12:16:00Z","isPatch":false,"sender":{"key":"thomas@koch.ro","avatar":null},"body":"Robert Clausecker:\n> I have a server that hosts a bare git repository. This git repository\n> contains a branch production. Whenever somebody pushes to production a\n> hook automatically puts a copy of the current production branch\n> into /var/www/foo. I could of course use pull for that but it just does\n> not feels right. Why should I have a repository twice on the server?\n\nHallo Robert,\n\nI've mostly the same requirement for a friend with a PHP webshop and started \nto implement my own git_export with the additional feature that it tries to \nreuse already exported trees as hardlink targets instead of writing the same \nfile again. (I'm aware of the dangers of hardlinks.)\n\nhttps://github.com/thkoch2001/git_export_hardlinks\n\nSee also the current mailing list thread: \"[Request] Git export with \nhardlinks\".\n\nBeste Grüße,\n\nThomas Koch, http://www.koch.ro\n"}]}