{"thread":{"id":"9644","subject":".gitignore, .gitattributes, .gitmodules, .gitprecious?, .gitacls? etc.","startedAt":"2007-08-26T02:59:26Z","lastAt":"2007-09-05T18:38:31Z","messageCount":28,"participants":["Dmitry Kakurin","Junio C Hamano","Petr Baudis","Johannes Schindelin","Sam Vilain","David Kastrup","martin f krafft","Sergio Callegari","Jan Hudec"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"51538","messageId":"2646CA4BEA644C9E9089C4A1AC395250@ntdev.corp.microsoft.com","threadId":"9644","inReplyTo":null,"subject":".gitignore, .gitattributes, .gitmodules, .gitprecious?, .gitacls? etc.","fromName":"Dmitry Kakurin","fromEmail":"dmitry.kakurin@gmail.com","sentAt":"2007-08-26T02:59:26Z","receivedAt":"2007-08-26T02:59:26Z","isPatch":false,"sender":{"key":"dmitry.kakurin@gmail.com","avatar":null},"body":"Git is using more and more .git* files to store metadata.\nI have two comments on this:\n1. It may be better to combine all these files into one (.gitmeta) with different sections\n2. Storing metadata in regular source-controlled files feels wrong to me. I cannot be very specific why (call it intuition), but \nsomething inside me screams \"bad design\" :-). We've already seen some chicken-and-the-egg problems with crlf and .gitattributes. So, \nmay be it would be better to keep this metadata only in repository (and index). One option would be to associate such a META object \nwith every TREE (an make it optional). Then allow editing this object with something like 'git meta'.\n\n- Dmitry \n"},{"id":"51543","messageId":"7v1wdqud0z.fsf@gitster.siamese.dyndns.org","threadId":"9644","inReplyTo":"2646CA4BEA644C9E9089C4A1AC395250@ntdev.corp.microsoft.com","subject":"Re: .gitignore, .gitattributes, .gitmodules, .gitprecious?, .gitacls? etc.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-08-26T04:37:32Z","receivedAt":"2007-08-26T04:37:32Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Dmitry Kakurin writes:\n\n> 1. It may be better to combine all these files into one (.gitmeta) with different sections\n\nMerging what has traditionally been known as .gitignore's\ncapability to attributes has been discussed, and I think it\nwould make sense in longer term, as 'this path pattern is to be\nignored' is just a special case of a more general attribute.\nAnd \"precious\" handling would naturally fit there. However, as\nthe .gitignore and .git/info/exclude has been as old as git\nitself (I think it was introduced around early May 2005), I do\nnot see us even start talking about deprecating .gitignore.\n\nI do not think .gitmodules fits the model of what .gitattributes\nsolves. .gitattributes is about the attribute of paths, while\n.gitmodules is about attribute of subprojects, and one attribute\nof a subproject is where in the superproject directory hierarchy\nit sits at.\n\nI do not know what you are talking about with .gitacls.\nPersonally I am not interested in turning git into a back-up\nprogram at all, so if you are talking beyond what has already\nbeen suggested as \"owner\", \"group\" and \"perms\" attributes that\ncould be stored in .gitattributes, I do not think it belongs to\ngit.\n\n> 2. Storing metadata in regular source-controlled files feels wrong to\n> me.\n\nYou are free to _feel_ whatever you want without thinking, but\nplease keep that _feeling_ to yourself, and speak it out after\nmaking it into an _opinion_, which would take a bit of thinking\nabout it first. For example, think about what you could do\nwithout confusing a total newbie after the initial clone. You\ncannot avoid chicken-and-egg problem. I think reading from\nindex as a fallback measure when work tree file is missing is a\nvery good compromise we came up recently. The wish of the user\n(i.e. the owner of the work tree) overrides what is in the\nindex, and the index is how the repository contents are\ninitially propagated back to the work tree.\n"},{"id":"51545","messageId":"52E107D8068148B795FB4279B6272B8E@ntdev.corp.microsoft.com","threadId":"9644","inReplyTo":"7v1wdqud0z.fsf@gitster.siamese.dyndns.org","subject":"Re: .gitignore, .gitattributes, .gitmodules, .gitprecious?, .gitacls? etc.","fromName":"Dmitry Kakurin","fromEmail":"dmitry.kakurin@gmail.com","sentAt":"2007-08-26T05:17:26Z","receivedAt":"2007-08-26T05:17:26Z","isPatch":false,"sender":{"key":"dmitry.kakurin@gmail.com","avatar":null},"body":"----- Original Message ----- \nFrom: \"Junio C Hamano\" \n >> 2. Storing metadata in regular source-controlled files feels wrong to\n>> me.\n> You are free to _feel_ whatever you want without thinking, but\n\nI did quite a bit of thinking before posting it. Not sure what made you think otherwise.\n\n> I think reading from\n> index as a fallback measure when work tree file is missing is a\n> very good compromise we came up recently.\n\nCan you specify _exactly_ how it works now? And I'll show you a bunch of corner cases where it's broken.\n\n- Dmitry\n"},{"id":"51546","messageId":"7vsl66svv4.fsf@gitster.siamese.dyndns.org","threadId":"9644","inReplyTo":"52E107D8068148B795FB4279B6272B8E@ntdev.corp.microsoft.com","subject":"Re: .gitignore, .gitattributes, .gitmodules, .gitprecious?, .gitacls? etc.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-08-26T05:33:35Z","receivedAt":"2007-08-26T05:33:35Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Dmitry Kakurin writes:\n\n> ----- Original Message ----- \n> From: \"Junio C Hamano\" \n>>> 2. Storing metadata in regular source-controlled files feels wrong to\n>>> me.\n>> You are free to _feel_ whatever you want without thinking, but\n>\n> I did quite a bit of thinking before posting it. Not sure what made you think otherwise.\n>\n>> I think reading from\n>> index as a fallback measure when work tree file is missing is a\n>> very good compromise we came up recently.\n>\n> Can you specify _exactly_ how it works now? And I'll show you a bunch of corner cases where it's broken.\n\nAs I made it clear, it is a compromise. I am not interested in\ndiscussing corner cases with you -- I am sure there are.\n\nIf you are offering improvements, I am all ears.\n"},{"id":"51547","messageId":"C22431BFCD8E403FA10C8E91DE8AC19A@ntdev.corp.microsoft.com","threadId":"9644","inReplyTo":"7vsl66svv4.fsf@gitster.siamese.dyndns.org","subject":"Re: .gitignore, .gitattributes, .gitmodules, .gitprecious?, .gitacls? etc.","fromName":"Dmitry Kakurin","fromEmail":"dmitry.kakurin@gmail.com","sentAt":"2007-08-26T06:36:43Z","receivedAt":"2007-08-26T06:36:43Z","isPatch":false,"sender":{"key":"dmitry.kakurin@gmail.com","avatar":null},"body":"----- Original Message ----- \nFrom: \"Junio C Hamano\" \n>> Can you specify _exactly_ how it works now? And I'll show you a bunch of corner cases where it's broken.\n>\n> As I made it clear, it is a compromise. I am not interested in\n> discussing corner cases with you -- I am sure there are.\n\nUsually many corner cases == design flaw.\n\n> If you are offering improvements, I am all ears.\n\nI thought I did: I've observed that these problem are caused by storing metadata in regular files (that exist both in repo/index and \nin workplace).\nMy knowledge of Git internals is quite limited, but if *I* were to do it right now, I'd introduce a META entry in every TREE object \nthat would point to a BLOB that contains combined content of .gitattributes, .gitignore etc. Then command like 'git meta' would open \nvi for this BLOB, let you edit it, and then would upload it back to index.\n\n- Dmitry\n"},{"id":"51548","messageId":"7vhcmmpxed.fsf@gitster.siamese.dyndns.org","threadId":"9644","inReplyTo":"C22431BFCD8E403FA10C8E91DE8AC19A@ntdev.corp.microsoft.com","subject":"Re: .gitignore, .gitattributes, .gitmodules, .gitprecious?, .gitacls? etc.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-08-26T07:28:42Z","receivedAt":"2007-08-26T07:28:42Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Dmitry Kakurin writes:\n\n> I thought I did: I've observed that these problem are caused by\n> storing metadata in regular files (that exist both in repo/index and\n> in workplace).\n\nAnd that observation solves the initial checkout issue how?\n\n> My knowledge of Git internals is quite limited, but if *I* were to do\n> it right now, I'd introduce a META entry in every TREE object that\n> would point to a BLOB that contains combined content of\n> .gitattributes, .gitignore etc.\n\nA tree that has .gitattributes (and I am assuming in the longer\nterm you can use \"ignore\" and \"precious\" in .gitattributes\ninstead of using .gitignore) POINTS TO A BLOB already, so what\nyou are saying does not add anything to what we already have,\nother than that you are renaming .gitattributes to \"META ENTRY\".\n\nWhen you do \"git checkout -- this-path\", you are checking things\nout from the index and at that point you may not have _any_ tree\nyet (think \"before initial commit\"). A \"META ENTRY\" that exists\nonly in a tree does not work -- it has to come to index somehow\nfor it to work with how git works.\n"},{"id":"51549","messageId":"B4A2AE9980774365B5D14B442A7A22F6@ntdev.corp.microsoft.com","threadId":"9644","inReplyTo":"7vhcmmpxed.fsf@gitster.siamese.dyndns.org","subject":"Re: .gitignore, .gitattributes, .gitmodules, .gitprecious?, .gitacls? etc.","fromName":"Dmitry Kakurin","fromEmail":"dmitry.kakurin@gmail.com","sentAt":"2007-08-26T08:02:50Z","receivedAt":"2007-08-26T08:02:50Z","isPatch":false,"sender":{"key":"dmitry.kakurin@gmail.com","avatar":null},"body":"----- Original Message ----- \nFrom: \"Junio C Hamano\" \n> Dmitry Kakurin writes:\n> \n>> I thought I did: I've observed that these problem are caused by\n>> storing metadata in regular files (that exist both in repo/index and\n>> in workplace).\n> \n> And that observation solves the initial checkout issue how?\nThere is always only one place to check for metadata - the index.\n\n>> My knowledge of Git internals is quite limited, but if *I* were to do\n>> it right now, I'd introduce a META entry in every TREE object that\n>> would point to a BLOB that contains combined content of\n>> .gitattributes, .gitignore etc.\n> \n> A tree that has .gitattributes (and I am assuming in the longer\n> term you can use \"ignore\" and \"precious\" in .gitattributes\n> instead of using .gitignore) POINTS TO A BLOB already, so what\n> you are saying does not add anything to what we already have,\n> other than that you are renaming .gitattributes to \"META ENTRY\".\n\nAlmost true! The difference is: META BLOBS are not created as files in the workspace (not during checkout, not ever).\nIn order to edit it you'd have to use 'git meta' command.\nSo once again, there is only one place to check for metadata - the index.\n\n> When you do \"git checkout -- this-path\", you are checking things\n> out from the index and at that point you may not have _any_ tree\n> yet (think \"before initial commit\"). A \"META ENTRY\" that exists\n> only in a tree does not work -- it has to come to index somehow\n> for it to work with how git works.\n\nI don't fully understand the difficulty. Here is how I see the initial checkin to work:\nLet's say you just did 'git init' and want to add file.txt with unusual crlf. So you don't want automatic translation.\nWhat you'll do is:\n* git meta\n In vi you put 'file.txt -crlf'\n git creates a TREE object in the index with only entry META that point to BLOB with this file.\n so it's kind of an empty tree from user's perspective.\n* git add file.txt\n while adding the file git consults META BLOB from the TREE (stored in index) and does not do any crlf translation\n the TREE now contains 2 entries: META, and BLOB for file.txt\n* git commit\n nothing special here\n\nNow someone else doing initial checkout:\n* git checkout\n Before writing file.txt to disk git consults META BLOB (in the index) and does not do any crlf translation.\n\n- Dmitry\n"},{"id":"51554","messageId":"20070826100647.GH1219@pasky.or.cz","threadId":"9644","inReplyTo":"B4A2AE9980774365B5D14B442A7A22F6@ntdev.corp.microsoft.com","subject":"Re: .gitignore, .gitattributes, .gitmodules, .gitprecious?, .gitacls? etc.","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2007-08-26T10:06:47Z","receivedAt":"2007-08-26T10:06:47Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Sun, Aug 26, 2007 at 10:02:50AM CEST, Dmitry Kakurin wrote:\n>>> My knowledge of Git internals is quite limited, but if *I* were to do\n>>> it right now, I'd introduce a META entry in every TREE object that\n>>> would point to a BLOB that contains combined content of\n>>> .gitattributes, .gitignore etc.\n>> A tree that has .gitattributes (and I am assuming in the longer\n>> term you can use \"ignore\" and \"precious\" in .gitattributes\n>> instead of using .gitignore) POINTS TO A BLOB already, so what\n>> you are saying does not add anything to what we already have,\n>> other than that you are renaming .gitattributes to \"META ENTRY\".\n>\n> Almost true! The difference is: META BLOBS are not created as files in the \n> workspace (not during checkout, not ever).\n> In order to edit it you'd have to use 'git meta' command.\n> So once again, there is only one place to check for metadata - the index.\n\nThat sounds so incredibly ugly, I really would hate to see that.\n\nIt's still not clear to me how this would help anything, though I didn't\nwatch late Git development. Can you explain some particular scenario\nwhere this would improve the current situation?\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nEver try. Ever fail. No matter. // Try again. Fail again. Fail better.\n\t\t-- Samuel Beckett\n"},{"id":"51559","messageId":"Pine.LNX.4.64.0708261656500.16728@wbgn129.biozentrum.uni-wuerzburg.de","threadId":"9644","inReplyTo":"52E107D8068148B795FB4279B6272B8E@ntdev.corp.microsoft.com","subject":"Re: .gitignore, .gitattributes, .gitmodules, .gitprecious?, .gitacls? etc.","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-08-26T15:05:19Z","receivedAt":"2007-08-26T15:05:19Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 25 Aug 2007, Dmitry Kakurin wrote:\n\n> ----- Original Message ----- From: \"Junio C Hamano\" \n> >> 2. Storing metadata in regular source-controlled files feels wrong to \n> >> me.\n> > You are free to _feel_ whatever you want without thinking, but\n> \n> I did quite a bit of thinking before posting it. Not sure what made you \n> think otherwise.\n\nWell, it certainly appears to me that your proposal to move metadata from \nthe working tree (where it is visible, and easily editable with the editor \nof _your_ choice) to the index (where it is hidden, and could only be \nedited with _yet another_ git command) is not well thought through.\n\nIt certainly would make some common operation much more complicated, for \nno gain at all.\n\nShould you still not be convinced, please find some convincing mails by \nLinus (which are much longer than I would have the patience to write) \nwhere he goes into detail _why_ it is _wrong_ to _hide_ things away from \nthe working tree.\n\n(Just a small hint: git is much more powerful _because_ it keeps metadata \nvisibly in the filesystem.)\n\nAs for your proposal to munge the different metadata files into sections \nof _one_ file: I doubt that this is \"cleaner\" or \"more elegant\" than what \nwe have now. For one, if a script fscks up one file, it does not fsck up \nthe others.\n\nFor another, scripts do not have to jump through hoops to edit the \nmetadata files, as long as they do not have sections (containing \ncompletely independent informations).\n\nCiao,\nDscho\n"},{"id":"51629","messageId":"46D23C48.6060904@vilain.net","threadId":"9644","inReplyTo":"B4A2AE9980774365B5D14B442A7A22F6@ntdev.corp.microsoft.com","subject":"Re: .gitignore, .gitattributes, .gitmodules, .gitprecious?, .gitacls? etc.","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2007-08-27T02:51:52Z","receivedAt":"2007-08-27T02:51:52Z","isPatch":false,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"Dmitry Kakurin wrote:\n>> A tree that has .gitattributes (and I am assuming in the longer\n>> term you can use \"ignore\" and \"precious\" in .gitattributes\n>> instead of using .gitignore) POINTS TO A BLOB already, so what\n>> you are saying does not add anything to what we already have,\n>> other than that you are renaming .gitattributes to \"META ENTRY\".\n>\n> Almost true! The difference is: META BLOBS are not created as files in\n> the workspace (not during checkout, not ever).\n> In order to edit it you'd have to use 'git meta' command.\n> So once again, there is only one place to check for metadata - the index.\n\nCan I just chime in here and express my distaste for this idea, on\nseveral grounds, but the summary is that svn does it this way, so it\nmust be wrong.\n\nThese files which store metadata would be stored in a way that is \"in\nanother dimension\" to the project files, despite being a part of the\nhistory. That means that all tools built to deal with regular files and\ndirectories will not be able to merge the changes to the attributes\nwithout special support. I think this is broken.\n\nThis is something I frequently run up against with people coming from\nSubversion, which supports unversioned revision properties which can\nchange randomly and without trace, and per-file/directory properties\nwhich are simply files which you can't refer to in the regular way, and\nare interpreted in an application-specific way.\n\nMy question to these people, and my question to you is: why do these\nfiles need to be served from another dimension, what value does it add?\n\nYou see, either way, their contents need to be processed in an\napplication-specific way. Same thing with git's \"commit properties\" -\nbasically just RFC822.. headers used in the commit message. People I\nhave talked to have described this as \"more arbitrary\" than conventions\nfor attributes which are structured. However, when pressed I have yet\nto hear a clear argument why this is the case.\n\nAs far as file properties goes, I still like Linus' idea of making these\nfiles which are accessed by treating the file as a directory (eg\nfilename.txt/ACL, filename.txt/mime-type), and that approach could be\nrepresented in git well.\n\nSam.\n"},{"id":"51636","messageId":"85ps19a5hm.fsf@lola.goethe.zz","threadId":"9644","inReplyTo":"46D23C48.6060904@vilain.net","subject":"Re: .gitignore, .gitattributes, .gitmodules, .gitprecious?, .gitacls? etc.","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-08-27T05:52:53Z","receivedAt":"2007-08-27T05:52:53Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Sam Vilain writes:\n\n> Dmitry Kakurin wrote:\n>>> A tree that has .gitattributes (and I am assuming in the longer\n>>> term you can use \"ignore\" and \"precious\" in .gitattributes\n>>> instead of using .gitignore) POINTS TO A BLOB already, so what\n>>> you are saying does not add anything to what we already have,\n>>> other than that you are renaming .gitattributes to \"META ENTRY\".\n>>\n>> Almost true! The difference is: META BLOBS are not created as files in\n>> the workspace (not during checkout, not ever).\n>> In order to edit it you'd have to use 'git meta' command.\n>> So once again, there is only one place to check for metadata - the index.\n>\n> Can I just chime in here and express my distaste for this idea, on\n> several grounds, but the summary is that svn does it this way, so it\n> must be wrong.\n>\n> These files which store metadata would be stored in a way that is\n> \"in another dimension\" to the project files, despite being a part of\n> the history. That means that all tools built to deal with regular\n> files and directories will not be able to merge the changes to the\n> attributes without special support. I think this is broken.\n\nThat presumes that a good way to merge attributes is to use a text\nfile merge algorithm, complete with finding diff context lines in a\nbasically unchanged order.\n\nAnd I don't see that this is a sensible merge strategy at all. No\nmatter where the attributes are stored, whether in a file or somewhere\nelse, any useful merge strategy would require an algorithm quite\ndifferent from the currently used one.\n\nNow this might be a case for pluggable merge strategies: after all,\nthere might be non-git related files with similar unordered per-line\nmerge semantics, or files expressing some information about files.\n\n> As far as file properties goes, I still like Linus' idea of making\n> these files which are accessed by treating the file as a directory\n> (eg filename.txt/ACL, filename.txt/mime-type), and that approach\n> could be represented in git well.\n\nWell, at least _some_ interesting Reiser4 idea resurfaces.\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"51682","messageId":"46D2ADF6.70100@vilain.net","threadId":"9644","inReplyTo":"85ps19a5hm.fsf@lola.goethe.zz","subject":"Re: .gitignore, .gitattributes, .gitmodules, .gitprecious?, .gitacls? etc.","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2007-08-27T10:56:54Z","receivedAt":"2007-08-27T10:56:54Z","isPatch":false,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"David Kastrup wrote:\n>> These files which store metadata would be stored in a way that is\n>> \"in another dimension\" to the project files, despite being a part of\n>> the history. That means that all tools built to deal with regular\n>> files and directories will not be able to merge the changes to the\n>> attributes without special support. I think this is broken.\n>> \n>\n> That presumes that a good way to merge attributes is to use a text\n> file merge algorithm, complete with finding diff context lines in a\n> basically unchanged order.\n> \n\nYes. Is that not a reasonable assumption, in the absence of anything\nmore enlightened?\n\n>> As far as file properties goes, I still like Linus' idea of making\n>> these files which are accessed by treating the file as a directory\n>> (eg filename.txt/ACL, filename.txt/mime-type), and that approach\n>> could be represented in git well.\n>> \n>\n> Well, at least _some_ interesting Reiser4 idea resurfaces.\n> \n\nThat was in there too? Man that Reiser4 manifesto read like the Naked\nLunch.\n\nSam.\n"},{"id":"51687","messageId":"86hcmltdzn.fsf@lola.quinscape.zz","threadId":"9644","inReplyTo":"46D2ADF6.70100@vilain.net","subject":"Re: .gitignore, .gitattributes, .gitmodules, .gitprecious?, .gitacls? etc.","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-08-27T11:26:36Z","receivedAt":"2007-08-27T11:26:36Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Sam Vilain writes:\n\n> David Kastrup wrote:\n>>> These files which store metadata would be stored in a way that is\n>>> \"in another dimension\" to the project files, despite being a part of\n>>> the history. That means that all tools built to deal with regular\n>>> files and directories will not be able to merge the changes to the\n>>> attributes without special support. I think this is broken.\n>>> \n>>\n>> That presumes that a good way to merge attributes is to use a text\n>> file merge algorithm, complete with finding diff context lines in a\n>> basically unchanged order.\n>> \n>\n> Yes. Is that not a reasonable assumption, in the absence of anything\n> more enlightened?\n\nIs that a trick question? My comment was exactly about not throwing\naway the information (\"This is not arbitrary text but talks about the\nfiles in our tree.\") that would make for more enlightened use.\n\n-- \nDavid Kastrup\n"},{"id":"51688","messageId":"Pine.LNX.4.64.0708271226360.28586@racer.site","threadId":"9644","inReplyTo":"46D2ADF6.70100@vilain.net","subject":"Re: .gitignore, .gitattributes, .gitmodules, .gitprecious?, .gitacls? etc.","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-08-27T11:30:26Z","receivedAt":"2007-08-27T11:30:26Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 27 Aug 2007, Sam Vilain wrote:\n\n> David Kastrup wrote:\n> >> These files which store metadata would be stored in a way that is\n> >> \"in another dimension\" to the project files, despite being a part of\n> >> the history. That means that all tools built to deal with regular\n> >> files and directories will not be able to merge the changes to the\n> >> attributes without special support. I think this is broken.\n> >> \n> >\n> > That presumes that a good way to merge attributes is to use a text\n> > file merge algorithm, complete with finding diff context lines in a\n> > basically unchanged order.\n> > \n> \n> Yes. Is that not a reasonable assumption, in the absence of anything\n> more enlightened?\n\nUmm.\n\nIt is not about _text_ file merge algorithms, but algorithms _outside of \ngit_!\n\nIf you tuck the stuff away in some obscure database where it is hard to \naccess, you make it more complicated and time consuming to access the data \nthan it needs to be to _begin with_.\n\n> >> As far as file properties goes, I still like Linus' idea of making \n> >> these files which are accessed by treating the file as a directory \n> >> (eg filename.txt/ACL, filename.txt/mime-type), and that approach \n> >> could be represented in git well.\n> >\n> > Well, at least _some_ interesting Reiser4 idea resurfaces.\n> \n> That was in there too? Man that Reiser4 manifesto read like the Naked \n> Lunch.\n\nIt is funny. No, I mean really funny. People criticise Reiser4, and only \npreciously few actually have ideas as good as in Reiser4. Yes, Reiser4 \nwas not developed as openly as it should have been. Yes, Hans was not the \nmost diplomatic poster ever, on lkml. No, even the stupid ideas in \nReiser4 are not half as stupid as mistaking the working tree for a place \nwhere only _text_ files reside.\n\nCiao,\nDscho\n"},{"id":"51690","messageId":"20070827113548.GA21977@piper.oerlikon.madduck.net","threadId":"9644","inReplyTo":"7v1wdqud0z.fsf@gitster.siamese.dyndns.org","subject":"Re: .gitignore, .gitattributes, .gitmodules, .gitprecious?, .gitacls? etc.","fromName":"martin f krafft","fromEmail":"madduck@madduck.net","sentAt":"2007-08-27T11:35:48Z","receivedAt":"2007-08-27T11:35:48Z","isPatch":false,"sender":{"key":"madduck@madduck.net","avatar":null},"body":"also sprach Junio C Hamano [2007.08.26.0637 +0200]:\n> > 1. It may be better to combine all these files into one\n> > (.gitmeta) with different sections\n> \n> Merging what has traditionally been known as .gitignore's\n> capability to attributes has been discussed, and I think it would\n> make sense in longer term, as 'this path pattern is to be ignored'\n> is just a special case of a more general attribute.\n\nI tried to find related threads in the archives but failed. If\nsomeone has a pointer handy, I'd appreciate it. Alternatively,\nplease feel free to just bounce related messages from your own\narchives to me.\n\nI am interested in this mainly because of a somewhat related idea of\nhonouring .gitignore/* in case it's a directory [0].\n\n0. http://marc.info/?l=git&m=118725982332041&w=2\n\n-- \nmartin; (greetings from the heart of the sun.)\n \\____ echo mailto: !#^.\"<*>\"|tr \"<*> mailto:\" net@madduck\n \n\"the question of whether computers can think\n is like the question of whether submarines can swim.\"\n -- edsgar w. dijkstra\n \nspamtraps: madduck.bogus@madduck.net\n"},{"id":"51720","messageId":"loom.20070827T172150-191@post.gmane.org","threadId":"9644","inReplyTo":"7v1wdqud0z.fsf@gitster.siamese.dyndns.org","subject":"Re: .gitignore, .gitattributes, .gitmodules, .gitprecious?, .gitacls? etc.","fromName":"Sergio Callegari","fromEmail":"scallegari@arces.unibo.it","sentAt":"2007-08-27T15:34:09Z","receivedAt":"2007-08-27T15:34:09Z","isPatch":false,"sender":{"key":"scallegari@arces.unibo.it","avatar":null},"body":"Junio C Hamano pobox.com> writes:\n\n> \n> Dmitry Kakurin gmail.com> writes:\n> \n> > 1. It may be better to combine all these files into one (.gitmeta) with\ndifferent sections\n> \n\nSorry about entering this discussion so late.\nI am just wondering about one thing.\n\nCouldn't all this directory/ownership/permission tracing be easily done by\nusing hooks?\nE.g. Having a pre-status and pre-commit hook one could fire up a program/script\nto collect all the extra info he wants to trace and store it somewhere\n(typically in some traced file).\nThe other way round one could have a post-checkout hook and he could arrange\nit to fire up some program to look into the extra-info file to set up\nall the meta-data he wants.\n\nThis would be very flexible and would permit to manage absolutely /any/ kind\nof the metadata leaving absolute freedom about how to do so.\n\nAm I missing something here?\n\nSergio\n"},{"id":"51725","messageId":"86odgtou5p.fsf@lola.quinscape.zz","threadId":"9644","inReplyTo":"loom.20070827T172150-191@post.gmane.org","subject":"Re: .gitignore, .gitattributes, .gitmodules, .gitprecious?, .gitacls? etc.","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-08-27T15:48:34Z","receivedAt":"2007-08-27T15:48:34Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Sergio Callegari writes:\n\n> Couldn't all this directory/ownership/permission tracing be easily\n> done by using hooks? E.g. Having a pre-status and pre-commit hook\n> one could fire up a program/script to collect all the extra info he\n> wants to trace and store it somewhere (typically in some traced\n> file). The other way round one could have a post-checkout hook and\n> he could arrange it to fire up some program to look into the\n> extra-info file to set up all the meta-data he wants.\n>\n> This would be very flexible and would permit to manage absolutely\n> /any/ kind of the metadata leaving absolute freedom about how to do\n> so.\n>\n> Am I missing something here?\n\nMerging.\n\n-- \nDavid Kastrup\n"},{"id":"51729","messageId":"20070827165416.GR1219@pasky.or.cz","threadId":"9644","inReplyTo":"86odgtou5p.fsf@lola.quinscape.zz","subject":"Re: .gitignore, .gitattributes, .gitmodules, .gitprecious?, .gitacls? etc.","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2007-08-27T16:54:16Z","receivedAt":"2007-08-27T16:54:16Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Mon, Aug 27, 2007 at 05:48:34PM CEST, David Kastrup wrote:\n> Sergio Callegari writes:\n> \n> > Couldn't all this directory/ownership/permission tracing be easily\n> > done by using hooks? E.g. Having a pre-status and pre-commit hook\n> > one could fire up a program/script to collect all the extra info he\n> > wants to trace and store it somewhere (typically in some traced\n> > file). The other way round one could have a post-checkout hook and\n> > he could arrange it to fire up some program to look into the\n> > extra-info file to set up all the meta-data he wants.\n> >\n> > This would be very flexible and would permit to manage absolutely\n> > /any/ kind of the metadata leaving absolute freedom about how to do\n> > so.\n> >\n> > Am I missing something here?\n> \n> Merging.\n\nFetching.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nEarly to rise and early to bed makes a male healthy and wealthy and dead.\n -- James Thurber\n"},{"id":"51732","messageId":"loom.20070827T185519-641@post.gmane.org","threadId":"9644","inReplyTo":"86odgtou5p.fsf@lola.quinscape.zz","subject":"Re: .gitignore, .gitattributes, .gitmodules, .gitprecious?, .gitacls? etc.","fromName":"Sergio Callegari","fromEmail":"scallegari@arces.unibo.it","sentAt":"2007-08-27T17:07:34Z","receivedAt":"2007-08-27T17:07:34Z","isPatch":false,"sender":{"key":"scallegari@arces.unibo.it","avatar":null},"body":"David Kastrup gnu.org> writes:\n\n> \n> Sergio Callegari arces.unibo.it> writes:\n> \n> > Couldn't all this directory/ownership/permission tracing be easily\n> > done by using hooks? E.g. Having a pre-status and pre-commit hook\n> > one could fire up a program/script to collect all the extra info he\n> > wants to trace and store it somewhere (typically in some traced\n> > file). The other way round one could have a post-checkout hook and\n> > he could arrange it to fire up some program to look into the\n> > extra-info file to set up all the meta-data he wants.\n> >\n> > This would be very flexible and would permit to manage absolutely\n> > /any/ kind of the metadata leaving absolute freedom about how to do\n> > so.\n> >\n> > Am I missing something here?\n> \n> Merging.\n> \n\nSorry, maybe I am really missing something, since merging does not look to me\nas an issue.\n\nWhy cannot git simply do the merging in the working tree as it normally\ndoes, including merging of the traced metadata file generated by the metadata\nhelpers invoked via the hooks?\nOnly, again more hooks are needed and likely a post-merge hook, so that at\nthe end of the merge, the metadata can be applied.\n\nOnly, to have things going on smoothly, one should be so wise to assure that\nthe metadata helpers save metadata as nice, sorted text files in order to\nminimize the burden of manual intervention if there are conflicts in\nmetadata merging.\n\nBTW. Having a post-checkout hook could also help getting rid of unwanted\nempty directories, couldn't it?\n \nSergio\n"},{"id":"51735","messageId":"loom.20070827T190921-993@post.gmane.org","threadId":"9644","inReplyTo":"20070827165416.GR1219@pasky.or.cz","subject":"Re: .gitignore, .gitattributes, .gitmodules, .gitprecious?, .gitacls? etc.","fromName":"Sergio Callegari","fromEmail":"scallegari@arces.unibo.it","sentAt":"2007-08-27T17:22:48Z","receivedAt":"2007-08-27T17:22:48Z","isPatch":false,"sender":{"key":"scallegari@arces.unibo.it","avatar":null},"body":"Petr Baudis suse.cz> writes:\n\n> \n> On Mon, Aug 27, 2007 at 05:48:34PM CEST, David Kastrup wrote:\n> > Sergio Callegari arces.unibo.it> writes:\n> > \n> > > Couldn't all this directory/ownership/permission tracing be easily\n> > > done by using hooks? E.g. Having a pre-status and pre-commit hook\n> > > one could fire up a program/script to collect all the extra info he\n> > > wants to trace and store it somewhere (typically in some traced\n> > > file). The other way round one could have a post-checkout hook and\n> > > he could arrange it to fire up some program to look into the\n> > > extra-info file to set up all the meta-data he wants.\n> > >\n> > > This would be very flexible and would permit to manage absolutely\n> > > /any/ kind of the metadata leaving absolute freedom about how to do\n> > > so.\n> > >\n> > > Am I missing something here?\n> > \n> > Merging.\n> \n> Fetching.\n> \n\nEven here, I must be missing something, as I cannot see the issue.\n\nIf I need to fetch from someone who is tracing metadata, then there are 2\nalternatives:\n\n1) I am fetching only for myself and I am not interested in metadata at all.\nAll I need to do is to fetch. With this I will fetch a repository with\none/some extra file/files (e.g. .helper-metadata).\n\n2) I am interested in the metadata tracing (e.g. to interact with\nmy origin). Then it is sufficient to first install the same set of\nmetadata tracing helpers as my origin and after that to do the fetch.\nWith this I will fetch a repository including the traced metadata files\njust as above, yet these would be immediately be used by the helpers\nthrough the hooks. For instance, as soon as anything gets checked out the\nproper metadata can be applied.\n\nObviously, before installing any hooks, I should trust their origin. But I\nbelieve that if hooks get this kind of usage, rapidly we will see\nthe growth of trustable \"standard\" hooks-bundles for many tasks.\n"},{"id":"51748","messageId":"a1bbc6950708271327x4dd948d4m8e9e35f757a7d92e@mail.gmail.com","threadId":"9644","inReplyTo":"4C603F7C51884DF8AFAEC3F6E263798D@ntdev.corp.microsoft.com","subject":".gitignore, .gitattributes, .gitmodules, .gitprecious?,.gitacls? etc.","fromName":"Dmitry Kakurin","fromEmail":"dmitry.kakurin@gmail.com","sentAt":"2007-08-27T20:27:48Z","receivedAt":"2007-08-27T20:27:48Z","isPatch":false,"sender":{"key":"dmitry.kakurin@gmail.com","avatar":null},"body":"----- Original Message -----\nFrom: \"Petr Baudis\" \n> On Sun, Aug 26, 2007 at 10:02:50AM CEST, Dmitry Kakurin wrote:\n>>>> My knowledge of Git internals is quite limited, but if *I* were to do\n>>>> it right now, I'd introduce a META entry in every TREE object that\n>>>> would point to a BLOB that contains combined content of\n>>>> .gitattributes, .gitignore etc.\n>>> A tree that has .gitattributes (and I am assuming in the longer\n>>> term you can use \"ignore\" and \"precious\" in .gitattributes\n>>> instead of using .gitignore) POINTS TO A BLOB already, so what\n>>> you are saying does not add anything to what we already have,\n>>> other than that you are renaming .gitattributes to \"META ENTRY\".\n>>\n>> Almost true! The difference is: META BLOBS are not created as files in the\n>> workspace (not during checkout, not ever).\n>> In order to edit it you'd have to use 'git meta' command.\n>> So once again, there is only one place to check for metadata - the index.\n>\n> It's still not clear to me how this would help anything, though I didn't\n> watch late Git development. Can you explain some particular scenario\n> where this would improve the current situation?\n\nHere is the problem: we need to apply crlf attributes to a file. We\ncould have .gitattributes both in the index and in the worktree.\nWhich one do we use?\nIn general .gitattributes file could be (U)nchanged, (C)hanged, (NP)\nNotPresent in each place.\nThis gives us 3x3 matrix = 9 special cases to handle. When you think\nabout this a little more you realize that even that\nis not enough and we need to take into account direction of data\nmovement (index -> filesystem or vice versa).\nThis doubles the matrix to 18 cases. Even if we come up with a very\ngood choice for every case (which is doubtful)\nthere is no way this could be *easily* explained to end user, or even memorized.\nThis leads to a simple idea that mostly works:\n1. when files are moved from index to filesystem, then only\n.gitattributes in the index is used, if it's not there == no special\nattributes.\n2. when files are moved from filesystem to index, then only\n.gitattributes in filesystem is used, again if it's not there == no\nspecial attributes.\n\nThen, in any operation, only one .gitattributes is taken into account.\nWe could stop here, but to me this redundancy still has some room for\nconfusion and looks unnecessary.\nPlus there is still room for unintentional abuse (by mistake).\n\nThat's why I think it's a good idea to always have only one .gitattributes.\n\n- Dmitry\n"},{"id":"52511","messageId":"20070904202326.GC3786@efreet.light.src","threadId":"9644","inReplyTo":"Pine.LNX.4.64.0708280945350.28586@racer.site","subject":"Re: .gitignore, .gitattributes, .gitmodules, .gitprecious?,.gitacls? etc.","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2007-09-04T20:23:26Z","receivedAt":"2007-09-04T20:23:26Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Tue, Aug 28, 2007 at 09:49:47 +0100, Johannes Schindelin wrote:\n> Hi,\n> \n> On Mon, 27 Aug 2007, Dmitry Kakurin wrote:\n> \n> > Here is the problem: we need to apply crlf attributes to a file. We\n> > could have .gitattributes both in the index and in the worktree.\n> > Which one do we use?\n> > In general .gitattributes file could be (U)nchanged, (C)hanged, (NP)\n> > NotPresent in each place.\n> \n> I do not see these cases. You can have these cases, basically:\n> \n> - .gitattributes in worktree (then it does not matter what else we have),\n> - .gitattributes not in the worktree, but in the index (then that is taken)\n> \n> In the latter case, there could be conflicts _in_ .gitattributes, in which \n> case those .gitattributes are ignored.\n> \n> I do not see any problem with that.\n\nI do.\n\nIMNSHO it should be the other way around:\n .gitattributes in index, than index version is used.\n .gitattributes not in index, but in worktree, than that tree version is used.\n\nWhy? Because when you check out another version, the .gitattributes commited\nin that version need to be applied, since it might be different from whatever\nis currently in the tree.\n\nIn the other direction, the tree version seems to make more sense, but in\nreality it does not. If you do a partial commit of a single file, than the\nindex version gets into the commit, so that should better be the version used\nto store the file. On the other hand if you change .gitattributes, the normal\ncommit rules are that you need to add it for commit, so needing to add it to\nmake it effective goes well together with it. update-index would need to\nalways handle .git* before other entries to make add . and commit -a work\ncorrectly.\n\nThe case for worktree only is for cases when you for some reason want to have\nlocal .gitattributes. Though I am not sure that should actually work, because\nyou couldn't have local .gitattributes if there is versioned version.\n.git/info/attributes would be better for that. Which gets us back to \"always\nuse .gitattributes from *index*\" (and read it from tree before other files\nwhen adding it).\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec \n"},{"id":"52513","messageId":"20070904204952.GD3786@efreet.light.src","threadId":"9644","inReplyTo":"Pine.LNX.4.64.0708290007020.28586@racer.site","subject":"Re: .gitignore, .gitattributes, .gitmodules, .gitprecious?, .gitacls? etc.","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2007-09-04T20:49:52Z","receivedAt":"2007-09-04T20:49:52Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Wed, Aug 29, 2007 at 00:07:55 +0100, Johannes Schindelin wrote:\n> On Wed, 29 Aug 2007, Sam Vilain wrote:\n> > Johannes Schindelin wrote:\n> > >> Ok, but let's say for a moment that file properties are allowed, and \n> > >> that they are stored in the Reiser4 fashion. On filesystems that did not \n> > >> support this, it would be the only way to get at them - to go through \n> > >> the index. Unless they were also mapped to regular files, or \n> > >> filesystem-specific features somehow.\n> > > \n> > > Happily, file properties as well hidden as these have _no_ _place_ in \n> > > source code that needs to be tracked.\n> > \n> > But you're restricting your statements to tidy, sane code bases. Are\n> > there any particular reasons that git shouldn't be able to track insane\n> > code bases, with attributes etc? It sure would shut up a whole load of\n> > people.\n> \n> To the contrary. People having those insane setups seem to be unable to \n> admit it. And I'm sure you saw some on this very list, like me. They \n> never shut up, they only get louder.\n\nWhether it's insane depends on whether you want to keep git purely for\nsource control -- in which case they are definitely insane -- or want to\nallow git to grow to a tool useful for other cases, like tracking content of\n/etc, whole filesystem images and similar stuff -- in which case most of\nthose setups are not insane at all.\n\nPersonally I would vote for a middle ground. To keep core git simple, but to\nprovide enough hooks to build the other tools on top of it. Enough hooks in\nthis case would mean (at least the way I can imagine as workable) hooks to\nrun when transfering files between worktree and index and place for the hooks\nto store the extra tracked information. This place could be some of special\nnamed file (.gitxattrs or anything) which would be updated in index by the\nhook, special index entries somehow related to individual filenames and/or\nheaders prepended to the blobs and trees. Any of those methods can be used\nfor storing permissions, acl, extended attributes and other random stuff and\ndifferent ones could be used by different hooks at the same time.\n\nEach of those methods has it's advantages and disadvantages. The special\nfiles are easiest to store if the hook is not available or can't represent\nthe data in given worktree -- simply make the special files regular. The\nentries attached to files (which are equivalent of extended attributes) would\nwork with standard merge on them (because they are handled individually) and\nthe headers to files would probably require least changes to git (I believe\nthey are implementable for files with git as is using the hook provided for\nkeyword expansion (or is it not there?)).\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec \n"},{"id":"52517","messageId":"20070904210349.GE3786@efreet.light.src","threadId":"9644","inReplyTo":"loom.20070827T185519-641@post.gmane.org","subject":"Re: .gitignore, .gitattributes, .gitmodules, .gitprecious?, .gitacls? etc.","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2007-09-04T21:03:49Z","receivedAt":"2007-09-04T21:03:49Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Mon, Aug 27, 2007 at 17:07:34 +0000, Sergio Callegari wrote:\n> David Kastrup gnu.org> writes:\n> \n> > \n> > Sergio Callegari arces.unibo.it> writes:\n> > \n> > > Couldn't all this directory/ownership/permission tracing be easily\n> > > done by using hooks? E.g. Having a pre-status and pre-commit hook\n> > > one could fire up a program/script to collect all the extra info he\n> > > wants to trace and store it somewhere (typically in some traced\n> > > file). The other way round one could have a post-checkout hook and\n> > > he could arrange it to fire up some program to look into the\n> > > extra-info file to set up all the meta-data he wants.\n> > >\n> > > This would be very flexible and would permit to manage absolutely\n> > > /any/ kind of the metadata leaving absolute freedom about how to do\n> > > so.\n> > >\n> > > Am I missing something here?\n> > \n> > Merging.\n> > \n> \n> Sorry, maybe I am really missing something, since merging does not look to me\n> as an issue.\n> \n> Why cannot git simply do the merging in the working tree as it normally\n> does, including merging of the traced metadata file generated by the metadata\n> helpers invoked via the hooks?\n> Only, again more hooks are needed and likely a post-merge hook, so that at\n> the end of the merge, the metadata can be applied.\n> \n> Only, to have things going on smoothly, one should be so wise to assure that\n> the metadata helpers save metadata as nice, sorted text files in order to\n> minimize the burden of manual intervention if there are conflicts in\n> metadata merging.\n\nThe post-checkout (no need for post-merge -- after in-index merge is done,\nthe files are checked out to worktree, so post-checkout would run anyway)\ncould actually apply any custom merge strategy required to avoid/clean up\nspurious conflicts in the metadata file (eg. adding two files that go after\neach other would be a textual conflict). The relevant versions are stored in\nindex stages at that point.\n\n> BTW. Having a post-checkout hook could also help getting rid of unwanted\n> empty directories, couldn't it?\n\nProbably not. I would imagine it would actually only run for the files being\nchecked out -- and there is nothing checked out in empty directories. (Well,\nit would run once or once per directory with list of checked out files on\nstandard input).\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec \n"},{"id":"52552","messageId":"a1bbc6950709050106j137215obd7272b2a77c3b13@mail.gmail.com","threadId":"9644","inReplyTo":"20070904202326.GC3786@efreet.light.src","subject":"Re: .gitignore, .gitattributes, .gitmodules, .gitprecious?,.gitacls? etc.","fromName":"Dmitry Kakurin","fromEmail":"dmitry.kakurin@gmail.com","sentAt":"2007-09-05T08:06:03Z","receivedAt":"2007-09-05T08:06:03Z","isPatch":false,"sender":{"key":"dmitry.kakurin@gmail.com","avatar":null},"body":"On 9/4/07, Jan Hudec wrote:\n> On Tue, Aug 28, 2007 at 09:49:47 +0100, Johannes Schindelin wrote:\n> > On Mon, 27 Aug 2007, Dmitry Kakurin wrote:\n> >\n> > > Here is the problem: we need to apply crlf attributes to a file. We\n> > > could have .gitattributes both in the index and in the worktree.\n> > > Which one do we use?\n> > > In general .gitattributes file could be (U)nchanged, (C)hanged, (NP)\n> > > NotPresent in each place.\n> >\n> > I do not see these cases. You can have these cases, basically:\n> >\n> > - .gitattributes in worktree (then it does not matter what else we have),\n> > - .gitattributes not in the worktree, but in the index (then that is taken)\n> >\n> > In the latter case, there could be conflicts _in_ .gitattributes, in which\n> > case those .gitattributes are ignored.\n> >\n> > I do not see any problem with that.\n>\n> I do.\n>\n> IMNSHO it should be the other way around:\n> .gitattributes in index, than index version is used.\n> .gitattributes not in index, but in worktree, than that tree version is used.\n\nConsider scenario when my commit #1 has .gitattributes:\n a.txt -nocrlf\nand file a.txt\nYou pull it.\nNow I make some changes to a.txt and realize that a.txt *is* a text\nfile now. I remove the entry from .gitattributes and notice that it\nbecomes empty. So I just remove .gitattributes file all together. It\nbecomes commit#2.\nNow you pull it again. There *is* .gitattributes in local directory,\nbut index does not have it (because I've removed it on purpose). What\nshould happen?\nI assert that since index does not have .gitattributes the one from\nlocal directory should not be used.\n\nThink about dedicated build machine scenario: I have a machine that\nalways does sync + build. After every sync the local directory should\nalways be identical to what-was-committed.\nWith every commit 3 things could happen: .gitattributes could appear,\ndisappear or change. In every case \"build machine\" must produce the\nexact copy of what-was-checked-in. The only way I see this happening\nis by using *only* index version of .gitattributes when files are\nmoved index -> workspace.\n\nA similar reasoning works for other direction (workplace -> index).\n-- \n- Dmitry\n"},{"id":"52553","messageId":"7vk5r5jzpn.fsf@gitster.siamese.dyndns.org","threadId":"9644","inReplyTo":"a1bbc6950709050106j137215obd7272b2a77c3b13@mail.gmail.com","subject":"Re: .gitignore, .gitattributes, .gitmodules, .gitprecious?,.gitacls? etc.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-09-05T08:14:44Z","receivedAt":"2007-09-05T08:14:44Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Dmitry Kakurin\" writes:\n\n> I assert that since index does not have .gitattributes the one from\n> local directory should not be used.\n>\n> Think about dedicated build machine scenario: I have a machine that\n> always does sync + build. After every sync the local directory should\n> always be identical to what-was-committed.\n\nThinking about the reason _why_ .gitattributes may be updated,\none would notice that it is because somebody did this command\nsequence:\n\n\tgit checkout\t\t;# now work tree is clean\n\tedit .gitattributes\t;# modify the attributes of a file\n\tedit file\t\t;# edit the file attributes talks about\n\tgit add file\t\t;# this can be affected by .gitattributes\n\tgit add .gitattributes\t;# this is changed in the same commit\n\tgit commit\n\nNow, should we always take .gitattributes from the index?\n"},{"id":"52557","messageId":"a1bbc6950709050131g397f1ef0p999681f8d13a8a42@mail.gmail.com","threadId":"9644","inReplyTo":"7vk5r5jzpn.fsf@gitster.siamese.dyndns.org","subject":"Re: .gitignore, .gitattributes, .gitmodules, .gitprecious?,.gitacls? etc.","fromName":"Dmitry Kakurin","fromEmail":"dmitry.kakurin@gmail.com","sentAt":"2007-09-05T08:31:33Z","receivedAt":"2007-09-05T08:31:33Z","isPatch":false,"sender":{"key":"dmitry.kakurin@gmail.com","avatar":null},"body":"On 9/5/07, Junio C Hamano wrote:\n> \"Dmitry Kakurin\" writes:\n>\n> > I assert that since index does not have .gitattributes the one from\n> > local directory should not be used.\n> >\n> > Think about dedicated build machine scenario: I have a machine that\n> > always does sync + build. After every sync the local directory should\n> > always be identical to what-was-committed.\n>\n> Thinking about the reason _why_ .gitattributes may be updated,\n> one would notice that it is because somebody did this command\n> sequence:\n>\n> git checkout ;# now work tree is clean\n> edit .gitattributes ;# modify the attributes of a file\n> edit file ;# edit the file attributes talks about\n> git add file ;# this can be affected by .gitattributes\n> git add .gitattributes ;# this is changed in the same commit\n> git commit\n>\n> Now, should we always take .gitattributes from the index?\nNo, from couple of my emails back:\n\n> This leads to a simple idea that mostly works:\n> 1. when files are moved from index to filesystem, then only .gitattributes in the index is used, if it's not there == no special attributes.\n> 2. when files are moved from filesystem to index, then only .gitattributes in filesystem is used, again if it's not there == no special attributes.\n>\n> Then, in any operation, only one .gitattributes is taken into account.\n\nThis is a must-do change (IMHO).\n\nTo go one step further (again IMHO) is to eliminate workspace version\nof .gitattributes all together:\n> We could stop here, but to me this redundancy still has some room for confusion and looks unnecessary.\n> Plus there is still room for unintentional abuse (by mistake).\n> That's why I think it's a good idea to always have only one .gitattributes (in the index).\n\n-- \n- Dmitry\n"},{"id":"52607","messageId":"20070905183831.GA29370@efreet.light.src","threadId":"9644","inReplyTo":"7vk5r5jzpn.fsf@gitster.siamese.dyndns.org","subject":"Re: .gitignore, .gitattributes, .gitmodules, .gitprecious?,.gitacls? etc.","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2007-09-05T18:38:31Z","receivedAt":"2007-09-05T18:38:31Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Wed, Sep 05, 2007 at 01:14:44 -0700, Junio C Hamano wrote:\n> \"Dmitry Kakurin\" writes:\n> \n> > I assert that since index does not have .gitattributes the one from\n> > local directory should not be used.\n> >\n> > Think about dedicated build machine scenario: I have a machine that\n> > always does sync + build. After every sync the local directory should\n> > always be identical to what-was-committed.\n> \n> Thinking about the reason _why_ .gitattributes may be updated,\n> one would notice that it is because somebody did this command\n> sequence:\n> \n> \tgit checkout\t\t;# now work tree is clean\n> \tedit .gitattributes\t;# modify the attributes of a file\n> \tedit file\t\t;# edit the file attributes talks about\n> \tgit add file\t\t;# this can be affected by .gitattributes\n> \tgit add .gitattributes\t;# this is changed in the same commit\n> \tgit commit\n> \n> Now, should we always take .gitattributes from the index?\n\nYes, they should:\n\n$ git checkout\n$ edit .gitattributes\n$ edit file\n$ git add file\n$ git commit ;# this does NOT have the changes to .gitattributes\n\nthe above case is a user error that can (at some cost) be detected:\n\n$ git checkout\n$ edit .gitattributes\n$ edit file\n$ git add file\n$ git add .gitattributes\nWarning! Changes to gitattributes affects handling of files scheduled for\ncommit. Please add following files again before commit:\n file\n$\n\nIt would be possible to special-case .gitattributes in add to:\n - do diff between the old and new value of .gitattributes in index,\n - list files changed in index compared to HEAD,\n - match each of them to all patterns in the diff,\n - if any matches, print the warning and list of matches.\nIt might be even possible to actually inspect the changes and apply those\nthat can be automatically (and not ask user to re-add), but some filters\nloose information, so user interaction is needed to add good version.\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec \n"}]}