{"thread":{"id":"12885","subject":".git/info/attributes not cloned","startedAt":"2008-03-27T03:08:30Z","lastAt":"2008-04-10T04:14:14Z","messageCount":13,"participants":["Toby Corkindale","Jeff King","Johannes Schindelin","Jakub Narebski","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"73178","messageId":"47EB0FAE.5000102@rea-group.com","threadId":"12885","inReplyTo":null,"subject":".git/info/attributes not cloned","fromName":"Toby Corkindale","fromEmail":"toby.corkindale@rea-group.com","sentAt":"2008-03-27T03:08:30Z","receivedAt":"2008-03-27T03:08:30Z","isPatch":false,"sender":{"key":"toby.corkindale@rea-group.com","avatar":null},"body":"Hi.\nIf one creates a .git/info/attributes file in a Git repo, it will not be \npresent in cloned repos.\nI don't know if this is a bug or not, but it /seems/ wrong behaviour to \nme, and reading from the manual pages.\n\nThis shell script demonstrates the issue:\n\n#!/bin/bash\nmkdir testgit\ncd testgit\nmkdir original\ncd original\ngit init --shared\necho -e \"# gitattributes(5) file\\n*.pm ident\" > .git/info/attributes\necho \"# \\$Ident\\$\" > example.pm\ngit add example.pm\ngit commit -m \"initial commit\"\ncd ..\ngit clone --bare original copy\nif [ -e copy/info/attributes ]; then\n     echo \"Good, attributes file exists.\"\nelse\n     echo \"Bad! attributes file does not exist in copy.\"\nfi\n"},{"id":"73180","messageId":"20080327033341.GB5417@coredump.intra.peff.net","threadId":"12885","inReplyTo":"47EB0FAE.5000102@rea-group.com","subject":"Re: .git/info/attributes not cloned","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-03-27T03:33:41Z","receivedAt":"2008-03-27T03:33:41Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Mar 27, 2008 at 02:08:30PM +1100, Toby Corkindale wrote:\n\n> If one creates a .git/info/attributes file in a Git repo, it will not be  \n> present in cloned repos.\n> I don't know if this is a bug or not, but it /seems/ wrong behaviour to  \n> me, and reading from the manual pages.\n\nIt is not a bug. The .gitattributes file in your working directory _is_\ncloned, and that is the right place to put things that you want to be\nrevision-controlled and used in every repo. The .git/info/attributes\nfile is for attributes that are purely local to that repo. This is\nsimilar to the split between .git/info/exclude and .gitignore.\n\nCan you point out which part of the manual gave the wrong impression (or\nbetter yet, submit a patch making it more clear)?\n\n-Peff\n"},{"id":"73181","messageId":"47EB213F.1020503@rea-group.com","threadId":"12885","inReplyTo":"20080327033341.GB5417@coredump.intra.peff.net","subject":"Re: .git/info/attributes not cloned","fromName":"Toby Corkindale","fromEmail":"toby.corkindale@rea-group.com","sentAt":"2008-03-27T04:23:27Z","receivedAt":"2008-03-27T04:23:27Z","isPatch":false,"sender":{"key":"toby.corkindale@rea-group.com","avatar":null},"body":"Jeff King wrote:\n> On Thu, Mar 27, 2008 at 02:08:30PM +1100, Toby Corkindale wrote:\n> \n>> If one creates a .git/info/attributes file in a Git repo, it will not be  \n>> present in cloned repos.\n>> I don't know if this is a bug or not, but it /seems/ wrong behaviour to  \n>> me, and reading from the manual pages.\n> \n> It is not a bug. The .gitattributes file in your working directory _is_\n> cloned, and that is the right place to put things that you want to be\n> revision-controlled and used in every repo. The .git/info/attributes\n> file is for attributes that are purely local to that repo. This is\n> similar to the split between .git/info/exclude and .gitignore.\n\nAh, OK.\nI was hoping not to use .gitattributes, as then the attributes are \nignored when doing something like:\ngit archive --remote=example.com:/path/to/repo release/v2.1 | tar xf -\n\n> Can you point out which part of the manual gave the wrong impression (or\n> better yet, submit a patch making it more clear)?\n\nNow that you've mentioned the difference between info/exclude and \n.gitignore, I see that in the docs/user-manual.html it is said:\n\n\"If you wish the exclude patterns to affect only certain repositories \n(instead of every repository for a given project), you may instead put \nthem in a file in your repository named .git/info/exclude, or in any \nfile specified by the core.excludesfile configuration variable.\"\n\nThat gives a clue that the /info/ files are repo-specific.\nHowever in gitignore(5) and gitattributes(5), there is no explanation of \nthis - it simply mentions that the info version is a higher priority \nthan the .git{ignore,attributes} version.\n\nI suggest that the individual docs/man-pages should mention that too.\nI'll submit a patch in a separate email, as long as I'm not still \nmisunderstanding the mechanism.\n\nIs there a recommended way to make attributes apply to commands run on a \nremote repository, or is that a different bug?\n\nthanks,\nToby\n"},{"id":"73183","messageId":"20080327042925.GA6426@coredump.intra.peff.net","threadId":"12885","inReplyTo":"47EB213F.1020503@rea-group.com","subject":"Re: .git/info/attributes not cloned","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-03-27T04:29:25Z","receivedAt":"2008-03-27T04:29:25Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Mar 27, 2008 at 03:23:27PM +1100, Toby Corkindale wrote:\n\n> Ah, OK.\n> I was hoping not to use .gitattributes, as then the attributes are  \n> ignored when doing something like:\n> git archive --remote=example.com:/path/to/repo release/v2.1 | tar xf -\n\nI vaguely recall some discussion of this in the past, so maybe it isn't\na good idea. But I would think changing git-archive to respect\n.gitattributes might be worth doing (presumably the version of\n.gitattributes from the tree that is being exported).\n\n> That gives a clue that the /info/ files are repo-specific.\n> However in gitignore(5) and gitattributes(5), there is no explanation of  \n> this - it simply mentions that the info version is a higher priority than \n> the .git{ignore,attributes} version.\n>\n> I suggest that the individual docs/man-pages should mention that too.\n> I'll submit a patch in a separate email, as long as I'm not still  \n> misunderstanding the mechanism.\n\nI think you understand what is going on. A clarification to both pages\nwould be helpful, I think, just saying \"here is why you might use one\nover the other.\"\n\n> Is there a recommended way to make attributes apply to commands run on a  \n> remote repository, or is that a different bug?\n\nI'm not sure what you mean here. Very few commands talk to remote\nrepositories. I had assumed in your git-archive example that you wanted\n.gitattributes on the remote repo to affect the tarfile generated by\nthat repo. But now it sounds like you want to edit a local file to\nimpact the archive generated remotely. I don't think there is a way to\ndo that.\n\n-Peff\n"},{"id":"73184","messageId":"47EB271F.1050307@rea-group.com","threadId":"12885","inReplyTo":"20080327042925.GA6426@coredump.intra.peff.net","subject":"Re: .git/info/attributes not cloned","fromName":"Toby Corkindale","fromEmail":"toby.corkindale@rea-group.com","sentAt":"2008-03-27T04:48:31Z","receivedAt":"2008-03-27T04:48:31Z","isPatch":false,"sender":{"key":"toby.corkindale@rea-group.com","avatar":null},"body":"Jeff King wrote:\n> On Thu, Mar 27, 2008 at 03:23:27PM +1100, Toby Corkindale wrote:\n> \n>> Ah, OK.\n>> I was hoping not to use .gitattributes, as then the attributes are  \n>> ignored when doing something like:\n>> git archive --remote=example.com:/path/to/repo release/v2.1 | tar xf -\n> \n> I vaguely recall some discussion of this in the past, so maybe it isn't\n> a good idea. But I would think changing git-archive to respect\n> .gitattributes might be worth doing (presumably the version of\n> .gitattributes from the tree that is being exported).\n\nRespecting the repo's .gitattributes would feel right. It seems unusual \n(to me) that it bypasses $REMOTE/.gitattributes, but DOES check \n$REMOTE/info/attributes.\n\n\n>> That gives a clue that the /info/ files are repo-specific.\n>> However in gitignore(5) and gitattributes(5), there is no explanation of  \n>> this - it simply mentions that the info version is a higher priority than \n>> the .git{ignore,attributes} version.\n>>\n>> I suggest that the individual docs/man-pages should mention that too.\n>> I'll submit a patch in a separate email, as long as I'm not still  \n>> misunderstanding the mechanism.\n> \n> I think you understand what is going on. A clarification to both pages\n> would be helpful, I think, just saying \"here is why you might use one\n> over the other.\"\n\nCheers. I've submitted my patch now. I hope I have the doc syntax right.\n\n>> Is there a recommended way to make attributes apply to commands run on a  \n>> remote repository, or is that a different bug?\n> \n> I'm not sure what you mean here. Very few commands talk to remote\n> repositories. I had assumed in your git-archive example that you wanted\n> .gitattributes on the remote repo to affect the tarfile generated by\n> that repo. But now it sounds like you want to edit a local file to\n> impact the archive generated remotely. I don't think there is a way to\n> do that.\n\nAh, no, you were right in your first assumption. I just wanted \ngit-archive to apply gitattributes to the resulting tarball.\n(I should have phrased that last line as \"..apply to commands connecting \nto a remote repo..\" and it would make more sense.)\n\nthanks,\nToby\n"},{"id":"73186","messageId":"20080327045342.GC6426@coredump.intra.peff.net","threadId":"12885","inReplyTo":"47EB271F.1050307@rea-group.com","subject":"Re: .git/info/attributes not cloned","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-03-27T04:53:42Z","receivedAt":"2008-03-27T04:53:42Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Mar 27, 2008 at 03:48:31PM +1100, Toby Corkindale wrote:\n\n>> I vaguely recall some discussion of this in the past, so maybe it isn't\n>> a good idea. But I would think changing git-archive to respect\n>> .gitattributes might be worth doing (presumably the version of\n>> .gitattributes from the tree that is being exported).\n>\n> Respecting the repo's .gitattributes would feel right. It seems unusual  \n> (to me) that it bypasses $REMOTE/.gitattributes, but DOES check  \n> $REMOTE/info/attributes.\n\nI agree that it seems like a bug. You might search the list archives for\ndiscussion around the export_subst attribute to see if it was discussed\nthen or if it is simply an omission.\n\n-Peff\n"},{"id":"73236","messageId":"47EC7DD1.3060102@rea-group.com","threadId":"12885","inReplyTo":"20080327045342.GC6426@coredump.intra.peff.net","subject":"[BUG?] git-archive ignores remote .gitattributes (was: .git/info/attributes not cloned)","fromName":"Toby Corkindale","fromEmail":"toby.corkindale@rea-group.com","sentAt":"2008-03-28T05:10:41Z","receivedAt":"2008-03-28T05:10:41Z","isPatch":false,"sender":{"key":"toby.corkindale@rea-group.com","avatar":null},"body":"Jeff King wrote:\n> On Thu, Mar 27, 2008 at 03:48:31PM +1100, Toby Corkindale wrote:\n> \n>>> I vaguely recall some discussion of this in the past, so maybe it isn't\n>>> a good idea. But I would think changing git-archive to respect\n>>> .gitattributes might be worth doing (presumably the version of\n>>> .gitattributes from the tree that is being exported).\n>> Respecting the repo's .gitattributes would feel right. It seems unusual  \n>> (to me) that it bypasses $REMOTE/.gitattributes, but DOES check  \n>> $REMOTE/info/attributes.\n> \n> I agree that it seems like a bug. You might search the list archives for\n> discussion around the export_subst attribute to see if it was discussed\n> then or if it is simply an omission.\n\nMy searches haven't turned anything up that seems relevant.\nI submit that this is a bug, or at least undesirable behaviour:\n\n\"git-archive --remote=/some/repo\" will ignore /some/repo/.gitattributes, \nbut check /some/repo/info/attributes.\n\nI think the problem is in the loop that looks for .gitattributes, which \nseems to do so by taking the current path and iterating down through it?\nIn the case of remote archives, shouldn't that start by taking the path \nof the repo, not current dir?\n\nOr should it go one step further, and check the .gitattributes for every \nfile it extracts? That is the behaviour you get if you run git-archive \nfrom within a repo, rather than remotely - and don't we want that to be \nconsistent with using --remote?\n\nie. I'm thinking of structures like:\n/myModule/testfile.pm\n/myModule/subdir/testfile.pm\n/myModule/subdir/.gitattributes\n\nif I do \"cd /myModule; git-archive HEAD\" then shouldn't I get the same \noutput as if I did \"cd /tmp; git-archive --remote=/myModule HEAD\" ?\n"},{"id":"73251","messageId":"alpine.LSU.1.00.0803281321260.18259@racer.site","threadId":"12885","inReplyTo":"47EC7DD1.3060102@rea-group.com","subject":"Re: [BUG?] git-archive ignores remote .gitattributes (was: .git/info/attributes not cloned)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-03-28T12:22:53Z","receivedAt":"2008-03-28T12:22:53Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 28 Mar 2008, Toby Corkindale wrote:\n\n> I submit that this is a bug, or at least undesirable behaviour:\n> \n> \"git-archive --remote=/some/repo\" will ignore /some/repo/.gitattributes, \n> but check /some/repo/info/attributes.\n> \n> I think the problem is in the loop that looks for .gitattributes, which \n> seems to do so by taking the current path and iterating down through it?\n\nThe problem is that \"git archive --remote\" operates on the remote \nrepository as if it were bare.  Which in many cases is true.\n\nSo I'd submit that this is not the usage .gitattributes is meant for, and \nthat you should clone the thing if you want to generate archives heeding \nthe .gitattributes.\n\nCiao,\nDscho\n"},{"id":"73255","messageId":"m3bq4zuhn5.fsf@localhost.localdomain","threadId":"12885","inReplyTo":"alpine.LSU.1.00.0803281321260.18259@racer.site","subject":"Re: [BUG?] git-archive ignores remote .gitattributes (was: .git/info/attributes not cloned)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-03-28T13:02:02Z","receivedAt":"2008-03-28T13:02:02Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n> On Fri, 28 Mar 2008, Toby Corkindale wrote:\n> \n> > I submit that this is a bug, or at least undesirable behaviour:\n> > \n> > \"git-archive --remote=/some/repo\" will ignore /some/repo/.gitattributes, \n> > but check /some/repo/info/attributes.\n> > \n> > I think the problem is in the loop that looks for .gitattributes, which \n> > seems to do so by taking the current path and iterating down through it?\n> \n> The problem is that \"git archive --remote\" operates on the remote \n> repository as if it were bare.  Which in many cases is true.\n> \n> So I'd submit that this is not the usage .gitattributes is meant for, and \n> that you should clone the thing if you want to generate archives heeding \n> the .gitattributes.\n\nThis is simply caused by lacking implementation of .gitattributes\n(which is quite new feature, so it is somewhat understandable).  \n\nAs I see it nothing prevents git to take and use .gitattributes from a\ngiven tree (from a top tree of a given commit)... well, nothing except\nthe fact that git-check-attr, and probably also API used by attributes\ncode in builtins, doesn't have place to provide blob to be used as\n.gitattributes (or tree to take .gitattributes from).\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"73258","messageId":"alpine.LSU.1.00.0803281422050.18259@racer.site","threadId":"12885","inReplyTo":"m3bq4zuhn5.fsf@localhost.localdomain","subject":"Re: [BUG?] git-archive ignores remote .gitattributes (was: .git/info/attributes not cloned)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-03-28T13:22:53Z","receivedAt":"2008-03-28T13:22:53Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 28 Mar 2008, Jakub Narebski wrote:\n\n> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n> \n> > On Fri, 28 Mar 2008, Toby Corkindale wrote:\n> > \n> > > I submit that this is a bug, or at least undesirable behaviour:\n> > > \n> > > \"git-archive --remote=/some/repo\" will ignore \n> > > /some/repo/.gitattributes, but check /some/repo/info/attributes.\n> > > \n> > > I think the problem is in the loop that looks for .gitattributes, \n> > > which seems to do so by taking the current path and iterating down \n> > > through it?\n> > \n> > The problem is that \"git archive --remote\" operates on the remote \n> > repository as if it were bare.  Which in many cases is true.\n> > \n> > So I'd submit that this is not the usage .gitattributes is meant for, \n> > and that you should clone the thing if you want to generate archives \n> > heeding the .gitattributes.\n> \n> This is simply caused by lacking implementation of .gitattributes (which \n> is quite new feature, so it is somewhat understandable).\n> \n> As I see it nothing prevents git to take and use .gitattributes from a \n> given tree (from a top tree of a given commit)... well, nothing except \n> the fact that git-check-attr, and probably also API used by attributes \n> code in builtins, doesn't have place to provide blob to be used as \n> .gitattributes (or tree to take .gitattributes from).\n\nOf course, you can ask for people to patch it.  Or even provide a patch \nyourself.  Personally, I do not think it is worth it.\n\nCiao,\nDscho\n"},{"id":"73397","messageId":"20080331024755.GA690@coredump.intra.peff.net","threadId":"12885","inReplyTo":"alpine.LSU.1.00.0803281321260.18259@racer.site","subject":"Re: [BUG?] git-archive ignores remote .gitattributes (was: .git/info/attributes not cloned)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-03-31T02:47:55Z","receivedAt":"2008-03-31T02:47:55Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Mar 28, 2008 at 01:22:53PM +0100, Johannes Schindelin wrote:\n\n> > \"git-archive --remote=/some/repo\" will ignore /some/repo/.gitattributes, \n> > but check /some/repo/info/attributes.\n> > \n> > I think the problem is in the loop that looks for .gitattributes, which \n> > seems to do so by taking the current path and iterating down through it?\n> \n> The problem is that \"git archive --remote\" operates on the remote \n> repository as if it were bare.  Which in many cases is true.\n> \n> So I'd submit that this is not the usage .gitattributes is meant for, and \n> that you should clone the thing if you want to generate archives heeding \n> the .gitattributes.\n\nI don't think it makes sense to operate on or take input from the\nworking tree of a remote; no other other command does, I don't think. I\nhad assumed, though, that .gitattributes files _in the tree being\nexported_ would be used.\n\nI thought there was some discussion of that a while ago (or possibly of\nlooking up .gitignore in the same way).\n\n-Peff\n"},{"id":"73399","messageId":"7vbq4vsiaa.fsf@gitster.siamese.dyndns.org","threadId":"12885","inReplyTo":"20080331024755.GA690@coredump.intra.peff.net","subject":"Re: [BUG?] git-archive ignores remote .gitattributes","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-03-31T03:07:25Z","receivedAt":"2008-03-31T03:07:25Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> I thought there was some discussion of that a while ago (or possibly of\n> looking up .gitignore in the same way).\n\nPerhaps we would want two distinct modes in dir.c (gitignore stack) and\nattr.c (gitattributes stack).  The current code implements the normal mode\nthat uses the files from the work tree (so that you can modify .gitigore\nand expect it to take effect immediately) and fall back to .index (as the\ngeneral principle, low-level part of git pretends missing files are\nunmodified files when they can).  The new mode, which would be appropriate\nfor commands such as \"archive\", would be triggered by first declaring that\nthe program is going to work on a single tree object, and will cause the\ngitignore and gitattributes to be read from that tree (and only that\ntree).\n\nEven a longer term clean-up would be (and this is probably a good GSoC\nsized project):\n\n - Unify gitignore and gitattributes stacks;\n\n - Maintain two or more gitignore/gitattributes stacks in effect at the\n   same time.  Things like \"git diff-tree $tree1 $tree2\", \"git diff-index\n   --cached $tree\", \"git diff-index $tree\", and \"git archive $tree\" should\n   take attr/ignore from their respective places.\n"},{"id":"74014","messageId":"47FD9416.1020403@rea-group.com","threadId":"12885","inReplyTo":"alpine.LSU.1.00.0803281321260.18259@racer.site","subject":"Re: [BUG?] git-archive ignores remote .gitattributes","fromName":"Toby Corkindale","fromEmail":"toby.corkindale@rea-group.com","sentAt":"2008-04-10T04:14:14Z","receivedAt":"2008-04-10T04:14:14Z","isPatch":false,"sender":{"key":"toby.corkindale@rea-group.com","avatar":null},"body":"Johannes Schindelin wrote:\n> Hi,\n> \n> On Fri, 28 Mar 2008, Toby Corkindale wrote:\n> \n>> I submit that this is a bug, or at least undesirable behaviour:\n>>\n>> \"git-archive --remote=/some/repo\" will ignore /some/repo/.gitattributes, \n>> but check /some/repo/info/attributes.\n>>\n>> I think the problem is in the loop that looks for .gitattributes, which \n>> seems to do so by taking the current path and iterating down through it?\n> \n> The problem is that \"git archive --remote\" operates on the remote \n> repository as if it were bare.  Which in many cases is true.\n> \n> So I'd submit that this is not the usage .gitattributes is meant for, and \n> that you should clone the thing if you want to generate archives heeding \n> the .gitattributes.\n\nIf it is not what .gitattributes is for, then what is?\nThe attributes docs even include specific options for archive mode \n(export-subst), which implies it is exactly meant for archive.\n\nHow about $GIT/info/attributes instead? Sadly, that isn't copied during \nclone.\n\nI'd rather not have to clone a potentially large repository just in \norder to make an archive of one specific version. If I was going to have \nto clone it, then I could pass appropriate options to rsync or tar to \narchive instead of calling git-archive.\n\nie. One could create this:\n\n#!/bin/bash\n# Usage: git-archive2  <repo> <treeish>\n# note - not actually a real script, don't run this.\nREPO=$1\nVERSION=$2\ngit clone $REPO\ncd `basename $REPO`\ngit checkout $VERSION\ntar cf - --exclude=.git\ncd ..\nrm -rf `basename $REPO`\n\n\nThat's silly and shouldn't be required, because git-archive --remote \nexists to perform that work. But it doesn't look at the attributes.\n\nIs there a better way?\n\nthanks,\nToby\n\n-- \nToby Corkindale\nSoftware developer\nw: www.rea-group.com\nREA Group refers to realestate.com.au Ltd (ASX:REA)\n\nWarning - This e-mail transmission may contain confidential information.\nIf you have received this transmission in error, please notify us\nimmediately on (61 3) 9897 1121 or by reply email to the sender. You\nmust destroy the e-mail immediately and not use, copy, distribute or\ndisclose the contents.\n"}]}