{"thread":{"id":"10403","subject":".gittattributes handling has deficiencies","startedAt":"2007-10-21T08:48:55Z","lastAt":"2007-10-22T13:04:41Z","messageCount":14,"participants":["Steffen Prohaska","david@lang.hm","Shawn O. Pearce","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"56757","messageId":"1192956535617-git-send-email-prohaska@zib.de","threadId":"10403","inReplyTo":null,"subject":".gittattributes handling has deficiencies","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-10-21T08:48:55Z","receivedAt":"2007-10-21T08:48:55Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"If a .gitattributes is in the work tree and we checkout a\ndifferent head, the .gitattributes of the head we are switching\nto must have precedence. Files are expected to be converted as\nconfigured in the .gitattributes that is available in the head\nwe're switching to.\n\nThis adds a test case revealing deficiencies of the current\nhandling of .gitattributes.\n\nAt a first glance, I saw two possible resolutions:\n1) .gitattributes from the index has precedence. It's unclear\n   how merging can be handled appropriately.\n2) .gitattributes are handled as a special file. Checkout is a\n   two pass process. In the first pass only the special file\n   .gitattributes is checked out. In th second pass the remaining\n   files are added. Maybe this gives a perspective how to handle\n   merges.\n\nBut actually the issue is much harder to solve.\n\nHere is what needs to be done: Whenever the attributes of a file\nchange the file must be freshly checked out according to the\nattributes of the head we switch to. The file itself does not\nnecessarily change between the two commits. A fresh checkout is\nalready needed if only .gitattributes change.\n\nBut this is really hard to solve. We would need to compare\nattributes before and after for _all_ files that have attributes\nin one of the two commits and check if they changed. If so, we\nneed to do a fresh checkout according to the new attributes.\n\nMaybe the gitattributes of a file should be part of the per-file\nflags in the index. Thus we could verify if the flags changed and\nif so, adjust the work tree accordig to the new flags.  I'm\nlacking a deeper insight into the git internals.  Therefore, I\ncan't really say if the index is the right place.  But it looks\nto me as if changing an attribute should be treated similar to a\nchanging sha1, as far as the work tree is concerned.\n\nSo, I need some help.\n    Steffen\n\n---\n t/t0020-crlf.sh |   23 +++++++++++++++++++++++\n 1 files changed, 23 insertions(+), 0 deletions(-)\n\ndiff --git a/t/t0020-crlf.sh b/t/t0020-crlf.sh\nindex 62bc4bb..5d7e033 100755\n--- a/t/t0020-crlf.sh\n+++ b/t/t0020-crlf.sh\n@@ -371,6 +371,29 @@ test_expect_success 'in-tree .gitattributes (4)' '\n \t}\n '\n \n+test_expect_success 'in-tree .gitattributes (5)' '\n+\n+\tgit reset --hard master &&\n+\techo >.gitattributes &&\n+\tgit add .gitattributes &&\n+\tgit commit -m \"empty .gitattributes\" &&\n+\trm -rf tmp one dir .gitattributes patch.file three &&\n+\tgit reset --hard master &&\n+\tgit checkout master^ &&\n+\n+\tif remove_cr one >/dev/null\n+\tthen\n+\t\techo \"Eh? one should not have CRLF\"\n+\t\tfalse\n+\telse\n+\t\t: happy\n+\tfi &&\n+\tremove_cr three >/dev/null || {\n+\t\techo \"Eh? three should still have CRLF\"\n+\t\tfalse\n+\t}\n+'\n+\n test_expect_success 'invalid .gitattributes (must not crash)' '\n \n \techo \"three +crlf\" >>.gitattributes &&\n-- \n1.5.3.mingw.1.138.g7bf9d\n"},{"id":"56760","messageId":"Pine.LNX.4.64.0710210204580.4818@asgard","threadId":"10403","inReplyTo":"1192956535617-git-send-email-prohaska@zib.de","subject":"Re: .gittattributes handling has deficiencies","fromName":"","fromEmail":"david@lang.hm","sentAt":"2007-10-21T09:19:14Z","receivedAt":"2007-10-21T09:19:14Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Sun, 21 Oct 2007, Steffen Prohaska wrote:\n\n> If a .gitattributes is in the work tree and we checkout a\n> different head, the .gitattributes of the head we are switching\n> to must have precedence. Files are expected to be converted as\n> configured in the .gitattributes that is available in the head\n> we're switching to.\n>\n> This adds a test case revealing deficiencies of the current\n> handling of .gitattributes.\n>\n> At a first glance, I saw two possible resolutions:\n> 1) .gitattributes from the index has precedence. It's unclear\n>   how merging can be handled appropriately.\n> 2) .gitattributes are handled as a special file. Checkout is a\n>   two pass process. In the first pass only the special file\n>   .gitattributes is checked out. In th second pass the remaining\n>   files are added. Maybe this gives a perspective how to handle\n>   merges.\n>\n> But actually the issue is much harder to solve.\n>\n> Here is what needs to be done: Whenever the attributes of a file\n> change the file must be freshly checked out according to the\n> attributes of the head we switch to.\n\nthis is the same problem that we would have with the extended file \nattributes, in the discussion for those it was suggested that I refrence \nthe file from the index rather then from the file system to avoid needing \nto do two passes.\n\n> The file itself does not\n> necessarily change between the two commits. A fresh checkout is\n> already needed if only .gitattributes change.\n>\n> But this is really hard to solve. We would need to compare\n> attributes before and after for _all_ files that have attributes\n> in one of the two commits and check if they changed. If so, we\n> need to do a fresh checkout according to the new attributes.\n\nif you know that you will get the new .gitattributes if it changes, setup \na post-checkout hook to checkout everything if it has changed. it's far \nfrom ideal, but it should be a good, safe, first approximation.\n\nyou shouldn't need to check all files of all attributes, only on any that \nmatch the lines that get changed. the hook for this is exactly the type of \nthing that I was talking about in the metastore thread.\n\n> Maybe the gitattributes of a file should be part of the per-file\n> flags in the index. Thus we could verify if the flags changed and\n> if so, adjust the work tree accordig to the new flags.  I'm\n> lacking a deeper insight into the git internals.  Therefore, I\n> can't really say if the index is the right place.  But it looks\n> to me as if changing an attribute should be treated similar to a\n> changing sha1, as far as the work tree is concerned.\n\nthe problem with this is that each attribute ends up needing it's own \nflag, which severely limits extending things (see the discussions on file \npermissions for examples). it's also much harder to manipulate them then \nin a file.\n\nDavid Lang\n\n> So, I need some help.\n>    Steffen\n>\n> ---\n> t/t0020-crlf.sh |   23 +++++++++++++++++++++++\n> 1 files changed, 23 insertions(+), 0 deletions(-)\n>\n> diff --git a/t/t0020-crlf.sh b/t/t0020-crlf.sh\n> index 62bc4bb..5d7e033 100755\n> --- a/t/t0020-crlf.sh\n> +++ b/t/t0020-crlf.sh\n> @@ -371,6 +371,29 @@ test_expect_success 'in-tree .gitattributes (4)' '\n> \t}\n> '\n>\n> +test_expect_success 'in-tree .gitattributes (5)' '\n> +\n> +\tgit reset --hard master &&\n> +\techo >.gitattributes &&\n> +\tgit add .gitattributes &&\n> +\tgit commit -m \"empty .gitattributes\" &&\n> +\trm -rf tmp one dir .gitattributes patch.file three &&\n> +\tgit reset --hard master &&\n> +\tgit checkout master^ &&\n> +\n> +\tif remove_cr one >/dev/null\n> +\tthen\n> +\t\techo \"Eh? one should not have CRLF\"\n> +\t\tfalse\n> +\telse\n> +\t\t: happy\n> +\tfi &&\n> +\tremove_cr three >/dev/null || {\n> +\t\techo \"Eh? three should still have CRLF\"\n> +\t\tfalse\n> +\t}\n> +'\n> +\n> test_expect_success 'invalid .gitattributes (must not crash)' '\n>\n> \techo \"three +crlf\" >>.gitattributes &&\n>\n"},{"id":"56766","messageId":"B61AE1A9-E983-4ACE-BF71-8FDC113A4F34@zib.de","threadId":"10403","inReplyTo":"Pine.LNX.4.64.0710210204580.4818@asgard","subject":"Re: .gittattributes handling has deficiencies","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-10-21T10:27:52Z","receivedAt":"2007-10-21T10:27:52Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Oct 21, 2007, at 11:19 AM, david@lang.hm wrote:\n\n>> But this is really hard to solve. We would need to compare\n>> attributes before and after for _all_ files that have attributes\n>> in one of the two commits and check if they changed. If so, we\n>> need to do a fresh checkout according to the new attributes.\n>\n> if you know that you will get the new .gitattributes if it changes,  \n> setup a post-checkout hook to checkout everything if it has  \n> changed. it's far from ideal, but it should be a good, safe, first  \n> approximation.\n\n\nThat's not good enough. I'll stop using .gitattributes. I\nneed to teach >40 devs how to use git on Windows. I only use\nfeatures that work flawlessly. .gitattributes doesn't. It bit\nme twice now.\n\nLuckily, core.autocrlf works if you set it before the first\ncheckout and never change it. This seems sufficient for me if\nall files that have mixed line endings are fixed right away.\n\n\tSteffen\n"},{"id":"56773","messageId":"Pine.LNX.4.64.0710211007430.4818@asgard","threadId":"10403","inReplyTo":"B61AE1A9-E983-4ACE-BF71-8FDC113A4F34@zib.de","subject":"Re: .gittattributes handling has deficiencies","fromName":"","fromEmail":"david@lang.hm","sentAt":"2007-10-21T17:09:35Z","receivedAt":"2007-10-21T17:09:35Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Sun, 21 Oct 2007, Steffen Prohaska wrote:\n\n> On Oct 21, 2007, at 11:19 AM, david@lang.hm wrote:\n>\n>>> But this is really hard to solve. We would need to compare\n>>> attributes before and after for _all_ files that have attributes\n>>> in one of the two commits and check if they changed. If so, we\n>>> need to do a fresh checkout according to the new attributes.\n>> \n>> if you know that you will get the new .gitattributes if it changes, setup a \n>> post-checkout hook to checkout everything if it has changed. it's far from \n>> ideal, but it should be a good, safe, first approximation.\n>\n>\n> That's not good enough. I'll stop using .gitattributes. I\n> need to teach >40 devs how to use git on Windows. I only use\n> features that work flawlessly. .gitattributes doesn't. It bit\n> me twice now.\n\nwhy would checking everything out if .gitattributes has changed not work? \nI can see why _not_ doing so would cause problems, and I freely \nacknowledge that this approach imposes a performance hit by checking \neverything out twice, but I don't see how it would not be reliable.\n\nDavid Lang\n\n> Luckily, core.autocrlf works if you set it before the first\n> checkout and never change it. This seems sufficient for me if\n> all files that have mixed line endings are fixed right away.\n>\n> \tSteffen\n"},{"id":"56774","messageId":"1A07FEE6-88D8-4ED7-BEFD-F7F3B71310A5@zib.de","threadId":"10403","inReplyTo":"Pine.LNX.4.64.0710211007430.4818@asgard","subject":"Re: .gittattributes handling has deficiencies","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-10-21T17:25:32Z","receivedAt":"2007-10-21T17:25:32Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Oct 21, 2007, at 7:09 PM, david@lang.hm wrote:\n\n> On Sun, 21 Oct 2007, Steffen Prohaska wrote:\n>\n>> On Oct 21, 2007, at 11:19 AM, david@lang.hm wrote:\n>>\n>>>> But this is really hard to solve. We would need to compare\n>>>> attributes before and after for _all_ files that have attributes\n>>>> in one of the two commits and check if they changed. If so, we\n>>>> need to do a fresh checkout according to the new attributes.\n>>> if you know that you will get the new .gitattributes if it  \n>>> changes, setup a post-checkout hook to checkout everything if it  \n>>> has changed. it's far from ideal, but it should be a good, safe,  \n>>> first approximation.\n>>\n>>\n>> That's not good enough. I'll stop using .gitattributes. I\n>> need to teach >40 devs how to use git on Windows. I only use\n>> features that work flawlessly. .gitattributes doesn't. It bit\n>> me twice now.\n>\n> why would checking everything out if .gitattributes has changed not  \n> work? I can see why _not_ doing so would cause problems, and I  \n> freely acknowledge that this approach imposes a performance hit by  \n> checking everything out twice, but I don't see how it would not be  \n> reliable.\n\nWhat do you mean by \"checking out everything\"?\nWhich command do you propose?\n\n\tSteffen\n"},{"id":"56775","messageId":"Pine.LNX.4.64.0710211056580.4818@asgard","threadId":"10403","inReplyTo":"1A07FEE6-88D8-4ED7-BEFD-F7F3B71310A5@zib.de","subject":"Re: .gittattributes handling has deficiencies","fromName":"","fromEmail":"david@lang.hm","sentAt":"2007-10-21T17:57:18Z","receivedAt":"2007-10-21T17:57:18Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Sun, 21 Oct 2007, Steffen Prohaska wrote:\n\n> On Oct 21, 2007, at 7:09 PM, david@lang.hm wrote:\n>\n>> On Sun, 21 Oct 2007, Steffen Prohaska wrote:\n>> \n>>> On Oct 21, 2007, at 11:19 AM, david@lang.hm wrote:\n>>> \n>>>>> But this is really hard to solve. We would need to compare\n>>>>> attributes before and after for _all_ files that have attributes\n>>>>> in one of the two commits and check if they changed. If so, we\n>>>>> need to do a fresh checkout according to the new attributes.\n>>>> if you know that you will get the new .gitattributes if it changes, setup \n>>>> a post-checkout hook to checkout everything if it has changed. it's far \n>>>> from ideal, but it should be a good, safe, first approximation.\n>>> \n>>> \n>>> That's not good enough. I'll stop using .gitattributes. I\n>>> need to teach >40 devs how to use git on Windows. I only use\n>>> features that work flawlessly. .gitattributes doesn't. It bit\n>>> me twice now.\n>> \n>> why would checking everything out if .gitattributes has changed not work? I \n>> can see why _not_ doing so would cause problems, and I freely acknowledge \n>> that this approach imposes a performance hit by checking everything out \n>> twice, but I don't see how it would not be reliable.\n>\n> What do you mean by \"checking out everything\"?\n> Which command do you propose?\n\nsomething like git checkout -f\n\nDavid Lang\n"},{"id":"56778","messageId":"C7F59DFB-D4E4-4F75-88F7-F1A90C7D41E8@zib.de","threadId":"10403","inReplyTo":"Pine.LNX.4.64.0710211056580.4818@asgard","subject":"Re: .gittattributes handling has deficiencies","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-10-21T20:21:31Z","receivedAt":"2007-10-21T20:21:31Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Oct 21, 2007, at 7:57 PM, david@lang.hm wrote:\n\n> On Sun, 21 Oct 2007, Steffen Prohaska wrote:\n>\n>> On Oct 21, 2007, at 7:09 PM, david@lang.hm wrote:\n>>\n>>> On Sun, 21 Oct 2007, Steffen Prohaska wrote:\n>>>> On Oct 21, 2007, at 11:19 AM, david@lang.hm wrote:\n>>>>>> But this is really hard to solve. We would need to compare\n>>>>>> attributes before and after for _all_ files that have attributes\n>>>>>> in one of the two commits and check if they changed. If so, we\n>>>>>> need to do a fresh checkout according to the new attributes.\n>>>>> if you know that you will get the new .gitattributes if it  \n>>>>> changes, setup a post-checkout hook to checkout everything if  \n>>>>> it has changed. it's far from ideal, but it should be a good,  \n>>>>> safe, first approximation.\n>>>> That's not good enough. I'll stop using .gitattributes. I\n>>>> need to teach >40 devs how to use git on Windows. I only use\n>>>> features that work flawlessly. .gitattributes doesn't. It bit\n>>>> me twice now.\n>>> why would checking everything out if .gitattributes has changed  \n>>> not work? I can see why _not_ doing so would cause problems, and  \n>>> I freely acknowledge that this approach imposes a performance hit  \n>>> by checking everything out twice, but I don't see how it would  \n>>> not be reliable.\n>>\n>> What do you mean by \"checking out everything\"?\n>> Which command do you propose?\n>\n> something like git checkout -f\n\nI suspected this. I see two problems:\n\n1) it's too dangerous: I throws away _all_ changes, not only\nchanges that are related to gitattributes.\n\n2) it doesn't work reliably. git checkout -f will only update\nfiles that git detects as changed. But you could have files that\nshould have crlf in the working copy but actually have only lf.\nThose would not be updated.\n\nI'll not recommend this. Not using .gitattributes is the only\nsane solution.\n\n\tSteffen\n"},{"id":"56790","messageId":"Pine.LNX.4.64.0710211645210.12998@asgard.lang.hm","threadId":"10403","inReplyTo":"C7F59DFB-D4E4-4F75-88F7-F1A90C7D41E8@zib.de","subject":"Re: .gittattributes handling has deficiencies","fromName":"","fromEmail":"david@lang.hm","sentAt":"2007-10-21T23:49:02Z","receivedAt":"2007-10-21T23:49:02Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Sun, 21 Oct 2007, Steffen Prohaska wrote:\n\n> On Oct 21, 2007, at 7:57 PM, david@lang.hm wrote:\n>\n>> On Sun, 21 Oct 2007, Steffen Prohaska wrote:\n>> \n>>> On Oct 21, 2007, at 7:09 PM, david@lang.hm wrote:\n>>> \n>>>> On Sun, 21 Oct 2007, Steffen Prohaska wrote:\n>>>>> On Oct 21, 2007, at 11:19 AM, david@lang.hm wrote:\n>>>>>>> But this is really hard to solve. We would need to compare\n>>>>>>> attributes before and after for _all_ files that have attributes\n>>>>>>> in one of the two commits and check if they changed. If so, we\n>>>>>>> need to do a fresh checkout according to the new attributes.\n>>>>>> if you know that you will get the new .gitattributes if it changes, \n>>>>>> setup a post-checkout hook to checkout everything if it has changed. \n>>>>>> it's far from ideal, but it should be a good, safe, first \n>>>>>> approximation.\n>>>>> That's not good enough. I'll stop using .gitattributes. I\n>>>>> need to teach >40 devs how to use git on Windows. I only use\n>>>>> features that work flawlessly. .gitattributes doesn't. It bit\n>>>>> me twice now.\n>>>> why would checking everything out if .gitattributes has changed not work? \n>>>> I can see why _not_ doing so would cause problems, and I freely \n>>>> acknowledge that this approach imposes a performance hit by checking \n>>>> everything out twice, but I don't see how it would not be reliable.\n>>> \n>>> What do you mean by \"checking out everything\"?\n>>> Which command do you propose?\n>> \n>> something like git checkout -f\n>\n> I suspected this. I see two problems:\n>\n> 1) it's too dangerous: I throws away _all_ changes, not only\n> changes that are related to gitattributes.\n\nthis is true, the question of if this is 'too dangerous' depends on what \nworkflow you teach as safe. if you teach that checking out a new version \nwill loose any modifications you have made (which is useually the sane \nthing to do by default anyway) then this is just more of the same\n\n> 2) it doesn't work reliably. git checkout -f will only update\n> files that git detects as changed. But you could have files that\n> should have crlf in the working copy but actually have only lf.\n> Those would not be updated.\n\nok, you could do rm -r * before doing the checkout -f (or there's probably \na option to git to tell it not to preserve changes to the working area, I \nam not a git guru.\n\n> I'll not recommend this. Not using .gitattributes is the only\n> sane solution.\n\nit may be the best thing to do for you and your users, that's not the same \nthing as saying that it's the only sane solution.\n\nDavid Lang\n"},{"id":"56792","messageId":"Pine.LNX.4.64.0710211703060.12998@asgard.lang.hm","threadId":"10403","inReplyTo":"Pine.LNX.4.64.0710211645210.12998@asgard.lang.hm","subject":"Re: .gittattributes handling has deficiencies","fromName":"","fromEmail":"david@lang.hm","sentAt":"2007-10-22T00:05:34Z","receivedAt":"2007-10-22T00:05:34Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Sun, 21 Oct 2007, david@lang.hm wrote:\n\n>>>> \n>>>> What do you mean by \"checking out everything\"?\n>>>> Which command do you propose?\n>>> \n>>> something like git checkout -f\n>> \n>> I suspected this. I see two problems:\n>> \n>> 1) it's too dangerous: I throws away _all_ changes, not only\n>> changes that are related to gitattributes.\n>\n> this is true, the question of if this is 'too dangerous' depends on what \n> workflow you teach as safe. if you teach that checking out a new version will \n> loose any modifications you have made (which is useually the sane thing to do \n> by default anyway) then this is just more of the same\n>\n>> 2) it doesn't work reliably. git checkout -f will only update\n>> files that git detects as changed. But you could have files that\n>> should have crlf in the working copy but actually have only lf.\n>> Those would not be updated.\n>\n> ok, you could do rm -r * before doing the checkout -f (or there's probably a \n> option to git to tell it not to preserve changes to the working area, I am \n> not a git guru.\n>\n>> I'll not recommend this. Not using .gitattributes is the only\n>> sane solution.\n>\n> it may be the best thing to do for you and your users, that's not the same \n> thing as saying that it's the only sane solution.\n\nby the way, I am not saying that my suggestion is the right way for things \nto be (especially long term), but I'm trying to figure out a work-around \nfor the short term.\n\nI'm very interested to see the logn-term suggestions, becouse I suspect \nthat modt of them could be leveraged for the metastore jobs.\n\nDavid Lang\n"},{"id":"56801","messageId":"20071022050111.GL14735@spearce.org","threadId":"10403","inReplyTo":"Pine.LNX.4.64.0710210204580.4818@asgard","subject":"Re: .gittattributes handling has deficiencies","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-10-22T05:01:11Z","receivedAt":"2007-10-22T05:01:11Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"david@lang.hm wrote:\n> On Sun, 21 Oct 2007, Steffen Prohaska wrote:\n> >If a .gitattributes is in the work tree and we checkout a\n> >different head, the .gitattributes of the head we are switching\n> >to must have precedence.\n> >\n> >Maybe the gitattributes of a file should be part of the per-file\n> >flags in the index. Thus we could verify if the flags changed and\n> >if so, adjust the work tree accordig to the new flags.  I'm\n> >lacking a deeper insight into the git internals.  Therefore, I\n> >can't really say if the index is the right place.  But it looks\n> >to me as if changing an attribute should be treated similar to a\n> >changing sha1, as far as the work tree is concerned.\n> \n> the problem with this is that each attribute ends up needing it's own \n> flag, which severely limits extending things (see the discussions on file \n> permissions for examples). it's also much harder to manipulate them then \n> in a file.\n\nYea, you really don't want to copy .gitattributes into the per-file\nrecords in the index.  That's not going to scale as more types of\nattributes are defined.\n\nFortunately the .gitattributes file format was designed to be\nreadable even when there's merge conflicts; that is it is a\nvery simple line-oriented record format.  One could difference\nthe old .gitattributes currently found in the index against the\n.gitattributes we are switching to (from the target tree-ish),\nscan the lines removed/added, find which files those match against\nin the target tree-ish, and just add those files to the list of\nthings we need to checkout.\n\nIf any of those files is dirty then we just refuse the checkout,\njust as if the file was modified and we were switching branches.\nThe user then needs to decide how to continue (probably stash the\nfile and then restart the checkout).\n\nRather simple IMHO.  Of course I haven't gone into that part of\nread-tree recently, and the .gitattribute parser reads from the\nworking directory, so you need to make sure you checkout the target\n.gitattributes file before anything else in the \"to process list\".\n\n-- \nShawn.\n"},{"id":"56805","messageId":"2C5D2967-A89F-4056-AD2A-0644B952C38F@zib.de","threadId":"10403","inReplyTo":"Pine.LNX.4.64.0710211703060.12998@asgard.lang.hm","subject":"Re: .gittattributes handling has deficiencies","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-10-22T05:38:28Z","receivedAt":"2007-10-22T05:38:28Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Oct 22, 2007, at 2:05 AM, david@lang.hm wrote:\n\n>\n> by the way, I am not saying that my suggestion is the right way for  \n> things to be (especially long term), but I'm trying to figure out a  \n> work-around for the short term.\n\nAnd I'm saying your proposed workaround is dangerous and doesn't\nwork reliably.\n\n> I'm very interested to see the logn-term suggestions, becouse I  \n> suspect that modt of them could be leveraged for the metastore jobs.\n\nI'd prefer this, too.\n\t\n\tSteffen\n"},{"id":"56817","messageId":"565E1D52-59C4-4EB8-AA81-FF94F346FE61@zib.de","threadId":"10403","inReplyTo":"20071022050111.GL14735@spearce.org","subject":"Re: .gittattributes handling has deficiencies","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-10-22T05:45:36Z","receivedAt":"2007-10-22T05:45:36Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Oct 22, 2007, at 7:01 AM, Shawn O. Pearce wrote:\n\n> david@lang.hm wrote:\n>> On Sun, 21 Oct 2007, Steffen Prohaska wrote:\n>>> If a .gitattributes is in the work tree and we checkout a\n>>> different head, the .gitattributes of the head we are switching\n>>> to must have precedence.\n>>>\n>>> Maybe the gitattributes of a file should be part of the per-file\n>>> flags in the index. Thus we could verify if the flags changed and\n>>> if so, adjust the work tree accordig to the new flags.  I'm\n>>> lacking a deeper insight into the git internals.  Therefore, I\n>>> can't really say if the index is the right place.  But it looks\n>>> to me as if changing an attribute should be treated similar to a\n>>> changing sha1, as far as the work tree is concerned.\n>>\n>> the problem with this is that each attribute ends up needing it's own\n>> flag, which severely limits extending things (see the discussions  \n>> on file\n>> permissions for examples). it's also much harder to manipulate  \n>> them then\n>> in a file.\n>\n> Yea, you really don't want to copy .gitattributes into the per-file\n> records in the index.  That's not going to scale as more types of\n> attributes are defined.\n>\n> Fortunately the .gitattributes file format was designed to be\n> readable even when there's merge conflicts; that is it is a\n> very simple line-oriented record format.  One could difference\n> the old .gitattributes currently found in the index against the\n> .gitattributes we are switching to (from the target tree-ish),\n> scan the lines removed/added, find which files those match against\n> in the target tree-ish, and just add those files to the list of\n> things we need to checkout.\n>\n> If any of those files is dirty then we just refuse the checkout,\n> just as if the file was modified and we were switching branches.\n> The user then needs to decide how to continue (probably stash the\n> file and then restart the checkout).\n\nSounds like a reasonable plan. I have no time to look into this\nright away.\n\n\n> Rather simple IMHO.  Of course I haven't gone into that part of\n> read-tree recently, and the .gitattribute parser reads from the\n> working directory, so you need to make sure you checkout the target\n> .gitattributes file before anything else in the \"to process list\".\n\n.gitattributes is first looked for in the working directory,\nand if not there, .gitattributes is read from the index.\n\n\tSteffen\n"},{"id":"56849","messageId":"Pine.LNX.4.64.0710221125350.25221@racer.site","threadId":"10403","inReplyTo":"565E1D52-59C4-4EB8-AA81-FF94F346FE61@zib.de","subject":"Re: .gittattributes handling has deficiencies","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-22T10:29:59Z","receivedAt":"2007-10-22T10:29:59Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 22 Oct 2007, Steffen Prohaska wrote:\n\n> .gitattributes is first looked for in the working directory, and if not \n> there, .gitattributes is read from the index.\n\nOf course we could change that to do it the other way round.  But this \nwould contradict expectations when you edit .gitattributes and then \ncheckout single files without having git-add'ed .gitattributes first.\n\nThe biggest problem in your setup, however, is not if .gitattributes is \nread from the index or the working directory.  The biggest problem is that \nfiles are not touched when their contents have not changed.\n\nIOW if you have .gitattributes in the to-be-checked-out branch which say \nthat README is crlf, and in the current branch it is not, and README's \n_contents_ are identical in both branches, a \"git checkout \n<that-other-branch>\" will not rewrite README, and consequently not change \nthe working copy to crlf.\n\nCiao,\nDscho\n"},{"id":"56868","messageId":"A524F676-BFFD-4AA7-8683-9623F12D2F2D@zib.de","threadId":"10403","inReplyTo":"Pine.LNX.4.64.0710221125350.25221@racer.site","subject":"Re: .gittattributes handling has deficiencies","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-10-22T13:04:41Z","receivedAt":"2007-10-22T13:04:41Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Oct 22, 2007, at 12:29 PM, Johannes Schindelin wrote:\n\n>\n> On Mon, 22 Oct 2007, Steffen Prohaska wrote:\n>\n>> .gitattributes is first looked for in the working directory, and  \n>> if not\n>> there, .gitattributes is read from the index.\n>\n> Of course we could change that to do it the other way round.  But this\n> would contradict expectations when you edit .gitattributes and then\n> checkout single files without having git-add'ed .gitattributes first.\n>\n> The biggest problem in your setup, however, is not  \n> if .gitattributes is\n> read from the index or the working directory.  The biggest problem  \n> is that\n> files are not touched when their contents have not changed.\n>\n> IOW if you have .gitattributes in the to-be-checked-out branch  \n> which say\n> that README is crlf, and in the current branch it is not, and README's\n> _contents_ are identical in both branches, a \"git checkout\n> <that-other-branch>\" will not rewrite README, and consequently not  \n> change\n> the working copy to crlf.\n\nExactly. The order of reading .gitattributes from the working\ndirectory or the index doesn't matter. The current mechanism\nhas a more fundamental deficiency.\n\nChanges of.gitattributes can influence how the same content\nis checked out to the work tree. If .gitattributes change the\ncheckout may need to be updated, even if the real content did\nnot change.\n\n\tSteffen\n"}]}