{"thread":{"id":"23180","subject":"`git check-attr' problems & questions","startedAt":"2010-03-26T03:57:00Z","lastAt":"2010-03-31T04:05:36Z","messageCount":12,"participants":["Eli Barzilay","Jonathan Nieder","Jakub Narebski","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"137824","messageId":"m3iq8jn3ar.fsf@winooski.ccs.neu.edu","threadId":"23180","inReplyTo":null,"subject":"`git check-attr' problems & questions","fromName":"Eli Barzilay","fromEmail":"eli@barzilay.org","sentAt":"2010-03-26T03:57:00Z","receivedAt":"2010-03-26T03:57:00Z","isPatch":false,"sender":{"key":"eli@barzilay.org","avatar":"https://avatars.githubusercontent.com/u/185905?v=4"},"body":"I'm trying to use .gitattributes to use some custom properties that we\nhave in an svn repository which is migrating to git, and there are\nsome two big problems with it that I'm running into:\n\n1. Looks like the path should always be the full path from the root,\n   even if I'm currently in a subdirectory, so:\n\n     cd $repo/foo/bar\n     git check-attr foo -- some-file # doesn't work\n     git check-attr foo -- foo/bar/some-file # works\n\n   Worse, if I happen to have an attribute for a toplevel `foo' file,\n   the first command produces that attribute.\n\n2. I'm also trying to use an attribute on a hook script on the server\n   (with the idea that email notifications are sent according to the\n   set of modified files) -- but it looks like `git check-attr'\n   doesn't work on a bare repository.  There's a \"worse\" part here\n   too: instead of showing an error, it actually succeeds after\n   showing that the attribute is \"unspecified\".\n\nSo my first question is -- am I missing something obvious?  It almost\nlooks like `check-attr' is intended only for low-level use...\n\nFixing the first problem seems like it would be easy with a quick\nshell script (maybe even with just an alias), but the second one is\nmore troubling.  Is there any way to do this on a bare repository\nwithout checking it out?\n\nAnd the last question -- is there anything that does something like\nthis customized email notifications that I'm trying to do?  (That is:\nan attribute that determines recipients, then a `post-receive' hook\nthat builds a list of modified files, grabs all the corresponding\nvalues of this attributes, and that's makes up the recipient list to\nnotify.)\n\n-- \n          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:\n                    http://barzilay.org/                   Maze is Life!\n"},{"id":"137986","messageId":"20100328014208.GA23015@progeny.tock","threadId":"23180","inReplyTo":"m3iq8jn3ar.fsf@winooski.ccs.neu.edu","subject":"Re: `git check-attr' problems & questions","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-03-28T01:42:08Z","receivedAt":"2010-03-28T01:42:08Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\n[quoted text reordered for convenience]\n\nEli Barzilay wrote:\n\n> I'm trying to use .gitattributes to use some custom properties that we\n> have in an svn repository which is migrating to git,\n[...]\n> So my first question is -- am I missing something obvious?  It almost\n> looks like `check-attr' is intended only for low-level use...\n\nYep.  It’s listed under “purehelpers” (Internal helper commands) in\ncommand-list.txt and hence git(1).  I suspect a good place to put\na user-visible equivalent would be a future ‘git ls’ command [1].\n\nTherefore...\n\n> Fixing the first problem seems like it would be easy with a quick\n> shell script (maybe even with just an alias),\n\nIf it proves pleasant to use, it would be very nice if you could send\na copy of such a shell script after a while.  Experiments like this\nare the foundation of a good UI.\n\n> 2. I'm also trying to use an attribute on a hook script on the server\n>    (with the idea that email notifications are sent according to the\n>    set of modified files) -- but it looks like `git check-attr'\n>    doesn't work on a bare repository.\n\nCurrent ‘git check-attr’ reads its attributes from actual .gitattribute\nfiles in the work tree first and then examines the versions registered\nin the index.  So the secret is to read the .gitattribute files you care\nabout into a temporary index file --- e.g., something like this.\n\n : \"Usage: $0 commit check-attr-args\" &&\n\n GIT_INDEX=tmp-index git read-tree --reset -i \"$1\" &&\n shift &&\n GIT_INDEX=tmp-index git check-attr \"$@\" &&\n rm tmp-index\n\nIdeally, check-attr should learn an option to set a different policy\n(e.g., index-only) with git_attr_set_direction(), but that is a\ndifferent story.\n\n>    instead of showing an error, it actually succeeds after\n>    showing that the attribute is \"unspecified\".\n\nProbably it should learn to error out when it expects to use a work\ntree but there is none.  git_attr_set_direction() does this.\n\n> And the last question -- is there anything that does something like\n> this customized email notifications that I'm trying to do?  (That is:\n> an attribute that determines recipients, then a `post-receive' hook\n> that builds a list of modified files, grabs all the corresponding\n> values of this attributes, and that's makes up the recipient list to\n> notify.)\n\nNot that I know of.\n\nHTH,\nJonathan\n\n[1] I read the name from here:\nhttp://thread.gmane.org/gmane.comp.version-control.git/136360\nThat series went in a different direction, though.\nhttp://thread.gmane.org/gmane.comp.version-control.git/141678\n"},{"id":"138096","messageId":"19376.50971.397375.810974@winooski.ccs.neu.edu","threadId":"23180","inReplyTo":"20100328014208.GA23015@progeny.tock","subject":"Re: `git check-attr' problems & questions","fromName":"Eli Barzilay","fromEmail":"eli@barzilay.org","sentAt":"2010-03-29T15:28:27Z","receivedAt":"2010-03-29T15:28:27Z","isPatch":false,"sender":{"key":"eli@barzilay.org","avatar":"https://avatars.githubusercontent.com/u/185905?v=4"},"body":"On Mar 27, Jonathan Nieder wrote:\n> Hi,\n> \n> [quoted text reordered for convenience]\n> \n> Eli Barzilay wrote:\n> \n> > I'm trying to use .gitattributes to use some custom properties that we\n> > have in an svn repository which is migrating to git,\n> [...]\n> > So my first question is -- am I missing something obvious?  It almost\n> > looks like `check-attr' is intended only for low-level use...\n> \n> Yep.  It’s listed under “purehelpers” (Internal helper commands) in\n> command-list.txt and hence git(1).\n\n(Ah, it would be nice to have that in the `git-check-attr' man page.)\n\n\n> I suspect a good place to put a user-visible equivalent would be a\n> future ‘git ls’ command [1].\n> \n> Therefore...\n> \n> > Fixing the first problem seems like it would be easy with a quick\n> > shell script (maybe even with just an alias),\n> \n> If it proves pleasant to use, it would be very nice if you could\n> send a copy of such a shell script after a while.  Experiments like\n> this are the foundation of a good UI.\n\nA script is easy, but even if it's for internal use, I don't see the\npoint in `check-attr' not doing so...\n\n> > 2. I'm also trying to use an attribute on a hook script on the server\n> >    (with the idea that email notifications are sent according to the\n> >    set of modified files) -- but it looks like `git check-attr'\n> >    doesn't work on a bare repository.\n> \n> Current ‘git check-attr’ reads its attributes from actual .gitattribute\n> files in the work tree first and then examines the versions registered\n> in the index.  So the secret is to read the .gitattribute files you care\n> about into a temporary index file --- e.g., something like this.\n> \n>  : \"Usage: $0 commit check-attr-args\" &&\n> \n>  GIT_INDEX=tmp-index git read-tree --reset -i \"$1\" &&\n>  shift &&\n>  GIT_INDEX=tmp-index git check-attr \"$@\" &&\n>  rm tmp-index\n\nI tried that, but it doesn't work.  (I used GIT_INDEX_FILE.)\n\n-- \n          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:\n                    http://barzilay.org/                   Maze is Life!\n"},{"id":"138104","messageId":"19376.53419.640007.930897@winooski.ccs.neu.edu","threadId":"23180","inReplyTo":"19376.50971.397375.810974@winooski.ccs.neu.edu","subject":"Re: `git check-attr' problems & questions","fromName":"Eli Barzilay","fromEmail":"eli@barzilay.org","sentAt":"2010-03-29T16:09:15Z","receivedAt":"2010-03-29T16:09:15Z","isPatch":false,"sender":{"key":"eli@barzilay.org","avatar":"https://avatars.githubusercontent.com/u/185905?v=4"},"body":"On Mar 29, Eli Barzilay wrote:\n> On Mar 27, Jonathan Nieder wrote:\n> >  : \"Usage: $0 commit check-attr-args\" &&\n> > \n> >  GIT_INDEX=tmp-index git read-tree --reset -i \"$1\" &&\n> >  shift &&\n> >  GIT_INDEX=tmp-index git check-attr \"$@\" &&\n> >  rm tmp-index\n> \n> I tried that, but it doesn't work.  (I used GIT_INDEX_FILE.)\n\nIn case I'm doing something wrong, here's a script that shows the\nproblem that I have:\n\n  #!/bin/sh\n  rm -rf /tmp/test\n  mkdir /tmp/test\n  cd /tmp/test\n  mkdir t\n  cd t\n  git init > /dev/null\n  echo \"Blah\" > foo\n  echo \"foo x=y\" > .gitattributes\n  git add foo .gitattributes\n  git commit -m \"stuff\" > /dev/null\n  echo -n \"check-attr in a working directory: \"\n  git check-attr x foo\n  cd ..\n  git clone --bare t > /dev/null\n  cd t.git\n  git read-tree --reset -i master\n  echo -n \"check-attr in a bare repository:   \"\n  git check-attr x foo\n\n-- \n          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:\n                    http://barzilay.org/                   Maze is Life!\n"},{"id":"138145","messageId":"20100329231501.GA28194@progeny.tock","threadId":"23180","inReplyTo":"19376.53419.640007.930897@winooski.ccs.neu.edu","subject":"git check-attr in bare repositories","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-03-29T23:15:01Z","receivedAt":"2010-03-29T23:15:01Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Eli Barzilay wrote:\n> On Mar 29, Eli Barzilay wrote:\n>> On Mar 27, Jonathan Nieder wrote:\n[in a bare repository]\n\n>>>  GIT_INDEX=tmp-index git check-attr \"$@\" &&\n[...]\n>> I tried that, but it doesn't work.  (I used GIT_INDEX_FILE.)\n\nYes, not sure how I confused myself.\n\ngit explicitly guards against that in attr.c.\n\n\t/*\n\t * Read from parent directories and push them down\n\t */\n\tif (!is_bare_repository() || direction == GIT_ATTR_INDEX) {\n\nThat check comes from v1.5.6-rc3~9^2 (Ignore .gitattributes in bare\nrepositories, 2008-06-08).  This is consistent with how bare\nrepositories generally work: they are guarded against use with a\npopulated index, since what filesystem tree would that index track?\n\nTo support your use case, it would be nice for check-attr to learn a\n--direction option.  Maybe it would be safe to let check-attr read\nfrom the index in bare repositories by default anyway, since the\nindex is usually missing anyway.\n\nProperly supporting general work in a bare repository would require\na larger effort.  Maybe:\n\n - Teach code that checks is_bare_repository() to check\n   get_git_work_tree() == NULL or similar instead.\n\n - Make the work_tree and git_dir variables the responsibility of the\n   setup code.\n\n - If the user sets GIT_INDEX_FILE or GIT_WORK_TREE, let the setup\n   code respect that wish even if core.bare is set.\n\nThoughts?\nJonathan\n"},{"id":"138157","messageId":"19377.33747.838003.360864@winooski.ccs.neu.edu","threadId":"23180","inReplyTo":"20100329231501.GA28194@progeny.tock","subject":"Re: git check-attr in bare repositories","fromName":"Eli Barzilay","fromEmail":"eli@barzilay.org","sentAt":"2010-03-30T04:53:39Z","receivedAt":"2010-03-30T04:53:39Z","isPatch":false,"sender":{"key":"eli@barzilay.org","avatar":"https://avatars.githubusercontent.com/u/185905?v=4"},"body":"On Mar 29, Jonathan Nieder wrote:\n> Eli Barzilay wrote:\n> > On Mar 29, Eli Barzilay wrote:\n> >> On Mar 27, Jonathan Nieder wrote:\n> [in a bare repository]\n> \n> >>>  GIT_INDEX=tmp-index git check-attr \"$@\" &&\n> [...]\n> >> I tried that, but it doesn't work.  (I used GIT_INDEX_FILE.)\n> \n> Yes, not sure how I confused myself.\n> \n> git explicitly guards against that in attr.c.\n> \n> \t/*\n> \t * Read from parent directories and push them down\n> \t */\n> \tif (!is_bare_repository() || direction == GIT_ATTR_INDEX) {\n\nUgh...!\n\n\n> That check comes from v1.5.6-rc3~9^2 (Ignore .gitattributes in bare\n> repositories, 2008-06-08).  This is consistent with how bare\n> repositories generally work: they are guarded against use with a\n> populated index, since what filesystem tree would that index track?\n\nWell, I've seen more than a few places that say that git attributes\nare the right choice to use for svn properties...  (I think that I\nalso asked a question about this here.)\n\nThere are a number of technicalities that make git attributes a poor\nsubstitute for svn properties -- mainly the fact that they limited in\ncontents (basically just short strings, no quoting, no newlines), and\nthe fact that they're not tracked with the files (as in svn, where\nmoving a file somewhere will move its properties with it).  Both of\nthese are not too bad for what we use them (files don't move often,\nand we use short strings only).  But having no access to them on the\nserver (without a costly checkout) is making it even more problematic,\nto the point that coming up with our own home cooked thing is easier\nthan using git attributes.  Given that they're not intended for\nend-user consumption (eg, `check-attr' being an internal helper) it\nlooks like we're not giving up much anyway.\n\n\n> To support your use case, it would be nice for check-attr to learn a\n> --direction option.  Maybe it would be safe to let check-attr read\n> from the index in bare repositories by default anyway, since the\n> index is usually missing anyway.\n\nWell, using the index this way seems like a kind of a hack anyway, so\nI'm not sure that there is any reason to do this.  If anything, I'd\nlike it if `check-attr' could just use the repository directly instead\nof the index (or a work tree) in a bare repository.  Without that, and\nthe best solution that I see in the short term, it should throw an\nappropriate error instead of just producing an \"unspecified\".\n\n-- \n          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:\n                    http://barzilay.org/                   Maze is Life!\n"},{"id":"138217","messageId":"20100330212222.GA11192@progeny.tock","threadId":"23180","inReplyTo":"19377.33747.838003.360864@winooski.ccs.neu.edu","subject":"Re: git check-attr in bare repositories","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-03-30T21:22:22Z","receivedAt":"2010-03-30T21:22:22Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Eli Barzilay wrote:\n\n> Well, using the index this way seems like a kind of a hack anyway, so\n> I'm not sure that there is any reason to do this.\n\nMost git commands do write out the tree they are working with to an\n(in-memory or on-disk) index, so using the index this way would make a\nwarped kind of sense.  But I agree that it is ugly.\n\n> If anything, I'd\n> like it if `check-attr' could just use the repository directly instead\n> of the index (or a work tree) in a bare repository.\n\nI think the right thing to do is to put this functionality in a new\n‘git ls’ command.  Maybe something like this:\n\n $ git ls --format='%p %a(crlf)' master -- '*.txt'\n some/path/foo.txt crlf:input\n some/path/bar.txt crlf\n some/path/other.txt !crlf\n yet/another/path.txt \n $\n\nI can not promise I will find time before the weekend to work on it.\nI wouldn’t be unhappy if someone else gets to it first.\n\nThanks for the explanations.\nJonathan\n"},{"id":"138218","messageId":"20100330213049.GB11192@progeny.tock","threadId":"23180","inReplyTo":"19377.33747.838003.360864@winooski.ccs.neu.edu","subject":"Carrying over attributes when moving files","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-03-30T21:30:49Z","receivedAt":"2010-03-30T21:30:49Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Eli Barzilay wrote:\n\n> There are a number of technicalities that make git attributes a poor\n> substitute for svn properties -- mainly\n[...]\n> and\n> the fact that they're not tracked with the files (as in svn, where\n> moving a file somewhere will move its properties with it).\n\nIt would be great to improve this.\n\nConsider the following directory hierarchy.\n\n\told-files/\n\t\t.gitattributes\n\t\tsome-file.html\n\t\tother-file.html\n\tnew-files/\n\t\tunrelated-file.html\n\n.gitattributes specifies that old HTML files use a CRLF line ending.\n\n\t*.html crlf\n\nWhat would you expect the following commands to do?\n\n\tgit mv old-files/some-file.html new-files/\n\tgit commit\n\nHow about these?\n\n\tmv old-files/some-file.html new-files/\n\tgit add new-files/some-file.html\n\tgit commit -a\n\nI don’t think there’s any fundamental reason this hasn’t been taken\ncare of; it’s just that nobody has done it yet.\n\nThoughts welcome.\nJonathan\n"},{"id":"138219","messageId":"m3iq8dij6r.fsf@localhost.localdomain","threadId":"23180","inReplyTo":"20100330212222.GA11192@progeny.tock","subject":"Re: git check-attr in bare repositories","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2010-03-30T21:39:25Z","receivedAt":"2010-03-30T21:39:25Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jonathan Nieder <jrnieder@gmail.com> writes:\n\n> Eli Barzilay wrote:\n> \n> > Well, using the index this way seems like a kind of a hack anyway, so\n> > I'm not sure that there is any reason to do this.\n> \n> Most git commands do write out the tree they are working with to an\n> (in-memory or on-disk) index, so using the index this way would make a\n> warped kind of sense.  But I agree that it is ugly.\n> \n> > If anything, I'd\n> > like it if `check-attr' could just use the repository directly instead\n> > of the index (or a work tree) in a bare repository.\n> \n> I think the right thing to do is to put this functionality in a new\n> ‘git ls’ command.  Maybe something like this:\n> \n>  $ git ls --format='%p %a(crlf)' master -- '*.txt'\n>  some/path/foo.txt crlf:input\n>  some/path/bar.txt crlf\n>  some/path/other.txt !crlf\n>  yet/another/path.txt \n>  $\n\nWell, that or make `git check-attr` support reading .gitattributes\nfrom repository (from a corresponding tree object).\n\nUnfortunately `git check-attr` doesn't have place to put revision...\nwell unless as a parameter:\n\n  git check-attr [--cached|--tree <tree-ish>] <attr>... [--] <pathname>...\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"138254","messageId":"19378.48750.465977.853886@winooski.ccs.neu.edu","threadId":"23180","inReplyTo":"20100330212222.GA11192@progeny.tock","subject":"Re: git check-attr in bare repositories","fromName":"Eli Barzilay","fromEmail":"eli@barzilay.org","sentAt":"2010-03-31T03:15:58Z","receivedAt":"2010-03-31T03:15:58Z","isPatch":false,"sender":{"key":"eli@barzilay.org","avatar":"https://avatars.githubusercontent.com/u/185905?v=4"},"body":"On Mar 30, Jonathan Nieder wrote:\n> Eli Barzilay wrote:\n> > If anything, I'd like it if `check-attr' could just use the\n> > repository directly instead of the index (or a work tree) in a\n> > bare repository.\n> \n> I think the right thing to do is to put this functionality in a new\n> ‘git ls’ command.  Maybe something like this:\n> \n>  $ git ls --format='%p %a(crlf)' master -- '*.txt'\n>  some/path/foo.txt crlf:input\n>  some/path/bar.txt crlf\n>  some/path/other.txt !crlf\n>  yet/another/path.txt \n\nThis looks useful, but it has a problem of being lower level than\n`check-attr' in the sense that you need to parse this output.\n\n\nOn Mar 30, Jakub Narebski wrote:\n> \n> Well, that or make `git check-attr` support reading .gitattributes\n> from repository (from a corresponding tree object).\n> \n> Unfortunately `git check-attr` doesn't have place to put revision...\n> well unless as a parameter:\n> \n>   git check-attr [--cached|--tree <tree-ish>] <attr>... [--] <pathname>...\n\nThis looks like a better way to have what I need from it...  It also\nlooks useful for other uses -- for example, an attribute that is used\nby a hook to specify that some file should not be deleted (so the hook\nneeds to look at the value before the commit).\n\n(But in any case, I'd be happy if there was a way to make it read the\ncontents of a (temporary) index.)\n\n-- \n          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:\n                    http://barzilay.org/                   Maze is Life!\n"},{"id":"138256","messageId":"19378.49617.251787.103542@winooski.ccs.neu.edu","threadId":"23180","inReplyTo":"20100330213049.GB11192@progeny.tock","subject":"Re: Carrying over attributes when moving files","fromName":"Eli Barzilay","fromEmail":"eli@barzilay.org","sentAt":"2010-03-31T03:30:25Z","receivedAt":"2010-03-31T03:30:25Z","isPatch":false,"sender":{"key":"eli@barzilay.org","avatar":"https://avatars.githubusercontent.com/u/185905?v=4"},"body":"On Mar 30, Jonathan Nieder wrote:\n> Eli Barzilay wrote:\n> \n> > There are a number of technicalities that make git attributes a\n> > poor substitute for svn properties -- mainly\n> [...]\n> > and the fact that they're not tracked with the files (as in svn,\n> > where moving a file somewhere will move its properties with it).\n> \n> It would be great to improve this.\n> \n> Consider the following directory hierarchy.\n> \n> \told-files/\n> \t\t.gitattributes\n> \t\tsome-file.html\n> \t\tother-file.html\n> \tnew-files/\n> \t\tunrelated-file.html\n> \n> .gitattributes specifies that old HTML files use a CRLF line ending.\n> \n> \t*.html crlf\n> \n> What would you expect the following commands to do?\n> \n> \tgit mv old-files/some-file.html new-files/\n> \tgit commit\n> \n> How about these?\n> \n> \tmv old-files/some-file.html new-files/\n> \tgit add new-files/some-file.html\n> \tgit commit -a\n> \n> I don’t think there’s any fundamental reason this hasn’t been taken\n> care of; it’s just that nobody has done it yet.\n\nThere's of course a whole bunch of similar issues, like having\n\n  a/.gitattribute specifies: b/c foo=bar\n  a/b/.gitattribute specifies: c foo=bar\n\nor even worse -- when the two values are different.\n\nIn any case, the way that attributes are specified (which is flexible\nand convenient, fwiw) is part of what makes them a bad substitution\nfor subversion properties...  Making attributes tracked with their\nfiles would mean some change to how this specification is done.  For\nexample, it could be that attributes that are in (tracked)\n.gitattribute files nad that have no \"/\" and no glob characters in the\nfile names are the only ones that get tracked.  In short -- only\nsimple names of immediate files and/or directories.  Having such a\nconvention would also allow some equivalent of `svn propset' since\nthere's a canonical place to add them.\n\nAnd this could be taken further -- for example, a command that will\ncrawl a tree and find \"non-canonicalized\" attributes, or will turn\nthem into such.  Another example would be to take something like\n\"*.html crlf\" as meaning that new *.html files should get the crlf\nattribute, etc.  But thinking about the kind of work that all of this\nwould imply, it seems to me that doing the svn thing and making the\nattributes part of the content (ie, make them a part of the blob\nobjects somehow) makes more sense.  But this is a big change too...\n\n-- \n          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:\n                    http://barzilay.org/                   Maze is Life!\n"},{"id":"138258","messageId":"7vzl1pp23z.fsf@alter.siamese.dyndns.org","threadId":"23180","inReplyTo":"20100330213049.GB11192@progeny.tock","subject":"Re: Carrying over attributes when moving files","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-03-31T04:05:36Z","receivedAt":"2010-03-31T04:05:36Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder <jrnieder@gmail.com> writes:\n\n> Consider the following directory hierarchy.\n>\n> \told-files/\n> \t\t.gitattributes\n> \t\tsome-file.html\n> \t\tother-file.html\n> \tnew-files/\n> \t\tunrelated-file.html\n>\n> .gitattributes specifies that old HTML files use a CRLF line ending.\n>\n> \t*.html crlf\n>\n> What would you expect the following commands to do?\n>\n> \tgit mv old-files/some-file.html new-files/\n> \tgit commit\n\nI know what you are getting at, but I think it cuts both ways.\n\nI can well imagine that the build structure where \"make && make install\"\nwill go to old-files and new-files directories and install the contents\noverlayed in the same destination, and .gitattributes may be being used as\na way to \"fix\" some aspect of \"oldness\" in old-files/ files until the\nsources are fixed.  So an equally valid work sequence might be:\n\n \tgit mv old-files/some-file.html new-files/\n\tedit new-files/some-file.html\n        git add new-files/some-file.html\n \tgit commit\n\nin which case adding a new \"some-file.html crlf\" entry to .gitattributes\nin new-files/ directory would be just _wrong_.\n\nSo I am not opposed to a mechanism to _let_ users makes a copy of an entry\nthat covers (or used to cover) one path to apply to another path that was\nnot covered by it, but doing it unconditionally would not be such a good\nidea.\n"}]}