{"thread":{"id":"59","subject":"Storing permissions","startedAt":"2005-04-16T23:00:58Z","lastAt":"2005-12-08T00:47:27Z","messageCount":25,"participants":["Martin Mares","Paul Jackson","Junio C Hamano","Morten Welinder","Linus Torvalds","David A. Wheeler","Daniel Barkalow","Zack Brown","Andreas Ericsson","Johannes Schindelin","Petr Baudis","H. Peter Anvin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"375","messageId":"20050416230058.GA10983@ucw.cz","threadId":"59","inReplyTo":null,"subject":"Storing permissions","fromName":"Martin Mares","fromEmail":"mj@ucw.cz","sentAt":"2005-04-16T23:00:58Z","receivedAt":"2005-04-16T23:00:58Z","isPatch":false,"sender":{"key":"mj@ucw.cz","avatar":null},"body":"Hi Linus et al.,\n\nI'm trying to use git, but I frequenty run into problems with file permissions\n-- some archives (including the master git archive) contain group-writable\nfiles, but when I check them out, the permissions get trimmed by my umask\n(quite sensibly) and update-cache complains that they need update.\n\nDoes it really make sense to store full permissions in the trees? I think\nthat remembering the x-bit should be good enough for almost all purposes\nand the other permissions should be left to the local environment.\n\nAnother possibility is to keep the permissions in the trees, but just make\nupdate-cache ignore differences in write permissions.\n\n\t\t\t\tHave a nice fortnight\n-- \nMartin `MJ' Mares http://atrey.karlin.mff.cuni.cz/~mj/\nFaculty of Math and Physics, Charles University, Prague, Czech Rep., Earth\nMan is the highest animal. Man does the classifying.\n"},{"id":"383","messageId":"20050416161935.0d2cf3b0.pj@sgi.com","threadId":"59","inReplyTo":"20050416230058.GA10983@ucw.cz","subject":"Re: Storing permissions","fromName":"Paul Jackson","fromEmail":"pj@sgi.com","sentAt":"2005-04-16T23:19:35Z","receivedAt":"2005-04-16T23:19:35Z","isPatch":false,"sender":{"key":"pj@sgi.com","avatar":null},"body":"Martin wrote:\n> Does it really make sense to store full permissions in the trees? I think\n> that remembering the x-bit should be good enough for almost all purposes\n> and the other permissions should be left to the local environment.\n\nThat matches my experience - store 1 bit of mode state - executable or not.\n\nLet local environment determine read, write and umask permissions.\n\n-- \n I won't rest till it's the best ...\n Programmer, Linux Scalability\n Paul Jackson 1.650.933.1373, 1.925.600.0401\n"},{"id":"391","messageId":"7vk6n247cd.fsf@assigned-by-dhcp.cox.net","threadId":"59","inReplyTo":"20050416161935.0d2cf3b0.pj@sgi.com","subject":"Re: Storing permissions","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-04-16T23:42:10Z","receivedAt":"2005-04-16T23:42:10Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":">>>>> \"PJ\" == Paul Jackson writes:\n\nPJ> That matches my experience - store 1 bit of mode state - executable or not.\n\nSounds like svn ;-).\n\n"},{"id":"397","messageId":"20050416170324.2cf934df.pj@sgi.com","threadId":"59","inReplyTo":"7vk6n247cd.fsf@assigned-by-dhcp.cox.net","subject":"Re: Storing permissions","fromName":"Paul Jackson","fromEmail":"pj@sgi.com","sentAt":"2005-04-17T00:03:24Z","receivedAt":"2005-04-17T00:03:24Z","isPatch":false,"sender":{"key":"pj@sgi.com","avatar":null},"body":"Junio wrote:\n> Sounds like svn \n\nI have no idea what svn is.\n\n-- \n I won't rest till it's the best ...\n Programmer, Linux Scalability\n Paul Jackson 1.650.933.1373, 1.925.600.0401\n"},{"id":"410","messageId":"118833cc05041618017fb32a2@mail.gmail.com","threadId":"59","inReplyTo":"20050416230058.GA10983@ucw.cz","subject":"Re: Storing permissions","fromName":"Morten Welinder","fromEmail":"mwelinder@gmail.com","sentAt":"2005-04-17T01:01:35Z","receivedAt":"2005-04-17T01:01:35Z","isPatch":false,"sender":{"key":"mwelinder@gmail.com","avatar":null},"body":"> Does it really make sense to store full permissions in the trees? I think\n> that remembering the x-bit should be good enough for almost all purposes\n> and the other permissions should be left to the local environment.\n\nIt makes some sense in principle, but without storing what they mean\n(i.e., group==?) it certainly makes no sense. It's a bit like unpacking a\ntar file.\n\nI suspect a non-readable file would cause a bit of a problem in the low-level\ncommands.\n\nMorten\n"},{"id":"416","messageId":"20050416183023.0b27b3a4.pj@sgi.com","threadId":"59","inReplyTo":"118833cc05041618017fb32a2@mail.gmail.com","subject":"Re: Storing permissions","fromName":"Paul Jackson","fromEmail":"pj@sgi.com","sentAt":"2005-04-17T01:30:23Z","receivedAt":"2005-04-17T01:30:23Z","isPatch":false,"sender":{"key":"pj@sgi.com","avatar":null},"body":"Morten wrote:\n> It makes some sense in principle, but without storing what they mean\n> (i.e., group==?) it certainly makes no sense. \n\nThere's no \"they\" there.\n\nI think Martin's proposal, to which I agreed, was to store a _single_\nbit. If any of the execute permissions of the incoming file are set,\nthen the bit is stored ON, else it is stored OFF. On 'checkout', if the\nbit is ON, then the file permission is set mode 0777 (modulo umask),\nelse it is set mode 0666 (modulo umask).\n\nYou might disagree that this is a good idea, but it certainly does\n'make sense' (as in 'is sensibly well defined').\n\n> I suspect a non-readable file would cause a bit of a problem in the low-level\n> commands.\n\nProbably so. If someone sets their umask 0333 or less, then they are\neither fools or QA (software quality assurance, or test) engineers.\n\n-- \n I won't rest till it's the best ...\n Programmer, Linux Scalability\n Paul Jackson 1.650.933.1373, 1.925.600.0401\n"},{"id":"435","messageId":"Pine.LNX.4.58.0504162138020.7211@ppc970.osdl.org","threadId":"59","inReplyTo":"20050416183023.0b27b3a4.pj@sgi.com","subject":"Re: Storing permissions","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-04-17T04:48:59Z","receivedAt":"2005-04-17T04:48:59Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 16 Apr 2005, Paul Jackson wrote:\n>\n> Morten wrote:\n> > It makes some sense in principle, but without storing what they mean\n> > (i.e., group==?) it certainly makes no sense. \n> \n> There's no \"they\" there.\n> \n> I think Martin's proposal, to which I agreed, was to store a _single_\n> bit. If any of the execute permissions of the incoming file are set,\n> then the bit is stored ON, else it is stored OFF. On 'checkout', if the\n> bit is ON, then the file permission is set mode 0777 (modulo umask),\n> else it is set mode 0666 (modulo umask).\n\nI think I agree.\n\nAnybody willing to send me a patch? One issue is that if done the obvious\nway it's an incompatible change, and old tree objects won't be valid any\nmore. It might be ok to just change the \"compare cache\" check to only care\nabout a few bits, though: S_IXUSR and S_IFDIR. And then always write new \n\"tree\" objects out with mode set to one of\n - 040000: we already do this for directories\n - 100644: normal files without S_IXUSR set\n - 100755: normal files _with_ S_IXUSR set\n\nThen, at compare time, we only look at S_IXUSR matching for files (we\nnever compare directory modes anyway). And at file create time, we create\nthem with 0666 and 0777 respectively, and let the users umask sort it out\n(and if the user has 0100 set in his umask, he can damn well blame\nhimself).\n\nThis would pretty much match the existing kernel tree, for example. We'd \nend up with some new trees there (and in git), but not a lot of \nincompatibility. And old trees would still work fine, they'd just get \nwritten out differently.\n\nAnybody want to send a patch to do this?\n\n\t\tLinus\n"},{"id":"437","messageId":"4261ED69.2060806@dwheeler.com","threadId":"59","inReplyTo":"20050416170324.2cf934df.pj@sgi.com","subject":"Re: Storing permissions","fromName":"David A. Wheeler","fromEmail":"dwheeler@dwheeler.com","sentAt":"2005-04-17T05:00:25Z","receivedAt":"2005-04-17T05:00:25Z","isPatch":false,"sender":{"key":"dwheeler@dwheeler.com","avatar":"https://avatars.githubusercontent.com/u/813150?v=4"},"body":"Paul Jackson wrote:\n> Junio wrote:\n> \n>>Sounds like svn \n> \n> \n> I have no idea what svn is.\n\nsvn = common abbreviation for \"Subversion\", a\nwidely-used centralized SCM tool intentionally\nsimilar to CVS.\n\n--- David A. Wheeler\n"},{"id":"442","messageId":"20050416223202.3d7c2a5f.pj@sgi.com","threadId":"59","inReplyTo":"Pine.LNX.4.58.0504162138020.7211@ppc970.osdl.org","subject":"Re: Storing permissions","fromName":"Paul Jackson","fromEmail":"pj@sgi.com","sentAt":"2005-04-17T05:32:02Z","receivedAt":"2005-04-17T05:32:02Z","isPatch":false,"sender":{"key":"pj@sgi.com","avatar":null},"body":"Linus wrote:\n> It might be ok to just change the \"compare cache\" check to only care\n> about a few bits, though: S_IXUSR and S_IFDIR. And then ...\n\nI think I agree. But since I am reluctant to take enough time to\nunderstand the code well enough to write this patch, I'll shut up now ;).\n\n-- \n I won't rest till it's the best ...\n Programmer, Linux Scalability\n Paul Jackson 1.650.933.1373, 1.925.600.0401\n"},{"id":"443","messageId":"Pine.LNX.4.58.0504162233050.7211@ppc970.osdl.org","threadId":"59","inReplyTo":"Pine.LNX.4.58.0504162138020.7211@ppc970.osdl.org","subject":"Re: Storing permissions","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-04-17T05:37:02Z","receivedAt":"2005-04-17T05:37:02Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 16 Apr 2005, Linus Torvalds wrote:\n> \n> Anybody want to send a patch to do this?\n\nActually, I just did it. Seems to work for the only test-case I tried,\nnamely I just committed it, and checked that the permissions all ended up\nbeing recorded as 0644 in the tree (if it has the -x bit set, they get\nrecorded as 0755).\n\nWhen checking out, we always check out with 0666 or 0777, and just let \numask do its thing. We only test bit 0100 when checking for differences.\n\nMaybe I missed some case, but this does indeed seem saner than the \"try to \nrestore all bits\" case. If somebody sees any problems, please holler.\n\n(Btw, you may or may not need to blow away your \"index\" file by just \nre-creating it with a \"read-tree\" after you've updated to this. I _tried_ \nto make sure that the compare just ignored the ce_mode bits, but the fact \nis, your index file may be \"corrupt\" in the sense that it has permission \nsets that sparse expects to never generate in an index file any more..)\n\n\t\tLinus\n"},{"id":"449","messageId":"42620092.9040402@dwheeler.com","threadId":"59","inReplyTo":"Pine.LNX.4.58.0504162138020.7211@ppc970.osdl.org","subject":"Re: Storing permissions","fromName":"David A. Wheeler","fromEmail":"dwheeler@dwheeler.com","sentAt":"2005-04-17T06:22:10Z","receivedAt":"2005-04-17T06:22:10Z","isPatch":false,"sender":{"key":"dwheeler@dwheeler.com","avatar":"https://avatars.githubusercontent.com/u/813150?v=4"},"body":"Linus Torvalds wrote:\n> \n> On Sat, 16 Apr 2005, Paul Jackson wrote:\n> \n>>Morten wrote:\n>>\n>>>It makes some sense in principle, but without storing what they mean\n>>>(i.e., group==?) it certainly makes no sense. \n>>\n>>There's no \"they\" there.\n>>\n>>I think Martin's proposal, to which I agreed, was to store a _single_\n>>bit. If any of the execute permissions of the incoming file are set,\n>>then the bit is stored ON, else it is stored OFF. On 'checkout', if the\n>>bit is ON, then the file permission is set mode 0777 (modulo umask),\n>>else it is set mode 0666 (modulo umask).\n> \n> \n> I think I agree.\n> \n> Anybody willing to send me a patch? One issue is that if done the obvious\n> way it's an incompatible change, and old tree objects won't be valid any\n> more. It might be ok to just change the \"compare cache\" check to only care\n> about a few bits, though: S_IXUSR and S_IFDIR.\n\nThere's a minor reason to write out ALL the perm bit data, but\nonly care about a few bits coming back in: Some people use\nSCM systems as a generalized backup system, so you can back up\nyour system to an arbitrary known state in the past\n(e.g., \"Change my /etc files to the state I was at\njust before I installed that &*#@ program!\").\nFor more on this, see:\n http://www.onlamp.com/pub/a/onlamp/2005/01/06/svn_homedir.html\n\nIf you store all the bits, then you CAN restore things\nmore exactly the way they were. This is imperfect, since\nit doesn't cover more exotic permission\nvalues from SELinux, xattrs, whatever. For some, that's enough.\n\nYeah, I know, not the main purpose of git. But what the heck,\nI _like_ flexible infrastructures.\n\n--- David A. Wheeler\n\n"},{"id":"456","messageId":"20050417011301.0b341d5d.pj@sgi.com","threadId":"59","inReplyTo":"42620092.9040402@dwheeler.com","subject":"Re: Storing permissions","fromName":"Paul Jackson","fromEmail":"pj@sgi.com","sentAt":"2005-04-17T08:13:01Z","receivedAt":"2005-04-17T08:13:01Z","isPatch":false,"sender":{"key":"pj@sgi.com","avatar":null},"body":"David wrote:\n> There's a minor reason to write out ALL the perm bit data, but\n\nThere's always the 'configurable option' approach.\n\nSomeone, I doubt Linus will have any interest in it, could volunteer to\nmake the masks of st_mode, used when storing and recovering file\npermissions, be configurable by some environment variable settings,\nwhich default to whatever Linus provided.\n\nBut, in general, if you want a generalized backup system, git is not it.\n\nGit skips all files whose name begins with the dot '.' character, and\nanything that is not a regular file or directory. Git makes no\nconcessions to working adequately on file systems lacking normal inode\nnumbers (such as smb, fat, vfat). Git obscures the archive format a\nmodest amount, for pure speed and to encourage use only via appropriate\nwrappers. Git is tuned for blazing speed at the operations that Linus\nneeds, not for trivial recovery, using the most basic tools, under harsh\ncircumstances.\n\nThe basic idea of using such an 'object database' (though I dislike that\nterm -- too high falutin vague) of files stored by their hash is a\ngood one. But a different core implementation is needed for backups.\n\nI have one that I use for my own backups, but it is written in Python,\nand uses MD5, one or the other of which likely disqualifies it from\nfurther consideration by half the readers of this list.\n\n-- \n I won't rest till it's the best ...\n Programmer, Linux Scalability\n Paul Jackson 1.650.933.1373, 1.925.600.0401\n"},{"id":"474","messageId":"Pine.LNX.4.21.0504171045150.30848-100000@iabervon.org","threadId":"59","inReplyTo":"42620092.9040402@dwheeler.com","subject":"Re: Storing permissions","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-04-17T14:51:49Z","receivedAt":"2005-04-17T14:51:49Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Sun, 17 Apr 2005, David A. Wheeler wrote:\n\n> There's a minor reason to write out ALL the perm bit data, but\n> only care about a few bits coming back in: Some people use\n> SCM systems as a generalized backup system, so you can back up\n> your system to an arbitrary known state in the past\n> (e.g., \"Change my /etc files to the state I was at\n> just before I installed that &*#@ program!\").\n> For more on this, see:\n> http://www.onlamp.com/pub/a/onlamp/2005/01/06/svn_homedir.html\n> \n> If you store all the bits, then you CAN restore things\n> more exactly the way they were. This is imperfect, since\n> it doesn't cover more exotic permission\n> values from SELinux, xattrs, whatever. For some, that's enough.\n\nI think this should be possible with a different tag than \"tree\". All the\nbits aren't sufficient, anyway; the unincluded values include the user and\ngroup, which are likely to matter for some things in /etc. But there's no\nreason that the core can't support both a system-local complete\nrepresentation of the dentry and a user-relative representation of a\nsource distribution with different tags.\n\nFor that matter, it could accept \"dir\" objects in commits as well, and use\nversion-control-type logic on history while refusing to do non-sensical\nthings with them.\n\n\t-Daniel\n*This .sig left intentionally blank*\n\n"},{"id":"490","messageId":"Pine.LNX.4.58.0504170857580.7211@ppc970.osdl.org","threadId":"59","inReplyTo":"42620092.9040402@dwheeler.com","subject":"Re: Storing permissions","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-04-17T16:10:25Z","receivedAt":"2005-04-17T16:10:25Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 17 Apr 2005, David A. Wheeler wrote:\n> \n> There's a minor reason to write out ALL the perm bit data, but\n> only care about a few bits coming back in: Some people use\n> SCM systems as a generalized backup system\n\nYes. I was actually thinking about having system config files in a git \nrepository when I started it, since I noticed how nicely it would do \nexactly that.\n\nHowever, since the mode bits also end up being part of the name of the \ntree object (ie they are most certainly part of the hash), it's really \nbasically impossible to only care about one bit but writing out many bits: \nit's the same issue of having multiple \"identical\" blocks with different \nnames.\n\nIt's ok if it happens occasionally (it _will_ happen at the point of a\ntree conversion to the new format, for example), but it's not ok if it\nhappens all the time - which it would, since some people have umask 002\n(and individual groups) and others have umask 022 (and shared groups), and\nI can imagine that some anal people have umask 0077 (\"I don't want to play\nwith others\").\n\nThe trees would constantly bounce between a million different combinations \n(since _some_ files would be checked out with the \"other\" mode).\n\nAt least if you always honor umask or always totally ignore umask, you get \na nice repetable thing. We tried the \"always ignore\" umask thing, and the \nproblem with that is that while _git_ ended up always doing a \"fchmod()\" \nto reset the whole permission mask, anybody who created files any other \nway and then checked them in would end up using umask.\n\nOne solution is to tell git with a command line flag and/or config file \nentry that \"for this repo, I want you to honor all bits\". That should be \neasy enough to add at some point, and then you really get what you want.\n\nThat said, git won't be really good at doing system backup. I actually \n_do_ save a full 32-bit of \"mode\" (hey, you could have \"immutable\" bits \netc set), but anybody who does anything fancy at all with mtime would be \nscrewed, for example.\n\nAlso, right now we don't actually save any other type of file than\nregular/directory, so you'd have to come up with a good save-format for\nsymlinks (easy, I guess - just make a \"link\" blob) and device nodes (that\none probably should be saved in the \"cache_entry\" itself, possibly\nencoded where the sha1 hash normally is).\n\nAlso, I made a design decision that git only cares about non-dotfiles. Git \nliterally never sees or looks at _anything_ that starts with a \".\". I \nthink that's absolutely the right thing to do for an SCM (if you hide your \nfiles, I really don't think you should expect the SCM to see it), but it's \nobviously not the right thing for a backup thing.\n\n(It _might_ be the right thing for a system config file, though, eg \ntracking something like \"/etc\" with git might be ok, modulo the other \nissues).\n\n\t\t\tLinus\n"},{"id":"492","messageId":"42628D1B.3000207@dwheeler.com","threadId":"59","inReplyTo":"Pine.LNX.4.58.0504170857580.7211@ppc970.osdl.org","subject":"Re: Storing permissions","fromName":"David A. Wheeler","fromEmail":"dwheeler@dwheeler.com","sentAt":"2005-04-17T16:21:47Z","receivedAt":"2005-04-17T16:21:47Z","isPatch":false,"sender":{"key":"dwheeler@dwheeler.com","avatar":"https://avatars.githubusercontent.com/u/813150?v=4"},"body":"Linus Torvalds wrote:\n> \n> On Sun, 17 Apr 2005, David A. Wheeler wrote:\n> \n>>There's a minor reason to write out ALL the perm bit data, but\n>>only care about a few bits coming back in: Some people use\n>>SCM systems as a generalized backup system\n> \n> Yes. I was actually thinking about having system config files in a git \n> repository when I started it, since I noticed how nicely it would do \n> exactly that.\n> \n> However, since the mode bits also end up being part of the name of the \n> tree object (ie they are most certainly part of the hash), it's really \n> basically impossible to only care about one bit but writing out many bits: \n> it's the same issue of having multiple \"identical\" blocks with different \n> names.\n...\n> One solution is to tell git with a command line flag and/or config file \n> entry that \"for this repo, I want you to honor all bits\". That should be \n> easy enough to add at some point, and then you really get what you want.\n\nYes, I thought of that too. And I agree, that should do the job.\n\nMy real concern is I'm looking at the early design of the\nstorage format so that it's POSSIBLE to extend git in obvious ways.\nAs long as it's possible later, then that's a great thing.\n\n...\n> Also, I made a design decision that git only cares about non-dotfiles. Git \n> literally never sees or looks at _anything_ that starts with a \".\". I \n> think that's absolutely the right thing to do for an SCM (if you hide your \n> files, I really don't think you should expect the SCM to see it), but it's \n> obviously not the right thing for a backup thing.\n\nAgain, a command line flag or config file entry could change that\nin the future, if desired. So this is a decision that could be\nchanged later... the best kind of decision :-).\n\n--- David A. Wheeler\n"},{"id":"552","messageId":"118833cc05041715157ea40ceb@mail.gmail.com","threadId":"59","inReplyTo":"42628D1B.3000207@dwheeler.com","subject":"Symlinks [was Re: Storing permissions]","fromName":"Morten Welinder","fromEmail":"mwelinder@gmail.com","sentAt":"2005-04-17T22:15:51Z","receivedAt":"2005-04-17T22:15:51Z","isPatch":false,"sender":{"key":"mwelinder@gmail.com","avatar":null},"body":"There's one more mode bit we might actually care about: the symlink bit.\n(One would store the target as the blob, presumably, but chmod isn't going\nto create symlinks out of regular files.)\n\nMorten\n"},{"id":"13315","messageId":"20051207145646.GA9207@tumblerings.org","threadId":"59","inReplyTo":"42628D1B.3000207@dwheeler.com","subject":"Re: dotfile support","fromName":"Zack Brown","fromEmail":"zbrown@tumblerings.org","sentAt":"2005-12-07T14:56:46Z","receivedAt":"2005-12-07T14:56:46Z","isPatch":false,"sender":{"key":"zbrown@tumblerings.org","avatar":null},"body":"Hi,\n\nWhat's the status of dotfile support? I can only find one thread that really\ndiscusses the issue:\n\nOn Sun, Apr 17, 2005 at 12:21:47PM -0400, David A. Wheeler wrote:\n> Linus Torvalds wrote:\n> >\n> >On Sun, 17 Apr 2005, David A. Wheeler wrote:\n> >\n> ...\n> >Also, I made a design decision that git only cares about non-dotfiles. Git \n> >literally never sees or looks at _anything_ that starts with a \".\". I \n> >think that's absolutely the right thing to do for an SCM (if you hide your \n> >files, I really don't think you should expect the SCM to see it), but it's \n> >obviously not the right thing for a backup thing.\n> \n> Again, a command line flag or config file entry could change that\n> in the future, if desired. So this is a decision that could be\n> changed later... the best kind of decision :-).\n\nPersonally I like dotfile support, and I compare it to the language encoding\nissue for filenames. Linus says we should treat filenames as binary data,\nand thus it won't matter what characters someone uses. I agree completely,\nbut by not supporting dotfiles, we're creating a big exception, in that if\na filename begins with a dot, we treat it in a much different way, in fact\nwe ignore it completely.\n\nIn the above quote, Linus says \"if you hide your files, I really don't think\nyou should expect the SCM to see it\". But what about the case where the\nuser is not the one choosing to create dotfiles? If I want to put a bunch of\nconfig files for various apps into a git repository, I don't get to pick their\nnames in many cases, at least not without changing the way I invoke my apps\n(or the scripts that do it for me). But it's still worthwhile to have those\nconfig files in version control. It makes it much easier to experiment with\nnew tools, recover from my mistakes, and share my successes with others.\n\nSo that's my pitch: Leaving out dotfile support seems like it creates an\nunnecessary limitation that eliminates some valid uses of git.\n\nBe well,\nZack\n\n> \n> --- David A. Wheeler\n> -\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n\n-- \nZack Brown\n"},{"id":"13316","messageId":"4396FFB0.4040203@op5.se","threadId":"59","inReplyTo":"20051207145646.GA9207@tumblerings.org","subject":"Re: dotfile support","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2005-12-07T15:28:48Z","receivedAt":"2005-12-07T15:28:48Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Zack Brown wrote:\n> Hi,\n> \n> What's the status of dotfile support? I can only find one thread that really\n> discusses the issue:\n> \n\nWhat sort of \"dotfile support\" are you hinting at? git being able to \nhandle them, or git being able to ignore them? Both are implemented. The \nformer by default and the latter through .gitignore.\n\nFiles you want to version-control ofcourse has to be added with \"git \nadd\", but that's not just dotfiles and it's really the only sane behaviour.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"13317","messageId":"Pine.LNX.4.63.0512071643110.12524@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"59","inReplyTo":"20051207145646.GA9207@tumblerings.org","subject":"Re: dotfile support","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2005-12-07T15:43:50Z","receivedAt":"2005-12-07T15:43:50Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 7 Dec 2005, Zack Brown wrote:\n\n> What's the status of dotfile support?\n\nIn the current git repository, \".gitignore\" is a versioned file.\n\nHth,\nDscho\n"},{"id":"13318","messageId":"20051207161130.GA10924@tumblerings.org","threadId":"59","inReplyTo":"4396FFB0.4040203@op5.se","subject":"Re: dotfile support","fromName":"Zack Brown","fromEmail":"zbrown@tumblerings.org","sentAt":"2005-12-07T16:11:30Z","receivedAt":"2005-12-07T16:11:30Z","isPatch":false,"sender":{"key":"zbrown@tumblerings.org","avatar":null},"body":"OK, I see my mistake.\n\nI should have tested better. I started off with a non-versioned directory\ncontaining dotfiles and regular files. I did a cg-init, only to discover\nthat the dotfiles were not included in the repository at that time. So I\njust assumed they couldn't be added either.\n\nBut I just tested, and yes indeed, it is possible to cg-add a dotfile.\n\nSo my question is, why does cg-init ignore dotfiles within the directory when it\nfirst initializes the repository?\n\nBe well,\nZack\n\nOn Wed, Dec 07, 2005 at 04:28:48PM +0100, Andreas Ericsson wrote:\n> Zack Brown wrote:\n> >Hi,\n> >\n> >What's the status of dotfile support? I can only find one thread that \n> >really\n> >discusses the issue:\n> >\n> \n> What sort of \"dotfile support\" are you hinting at? git being able to \n> handle them, or git being able to ignore them? Both are implemented. The \n> former by default and the latter through .gitignore.\n> \n> Files you want to version-control ofcourse has to be added with \"git \n> add\", but that's not just dotfiles and it's really the only sane behaviour.\n> \n> -- \n> Andreas Ericsson andreas.ericsson@op5.se\n> OP5 AB www.op5.se\n> Tel: +46 8-230225 Fax: +46 8-230231\n> -\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n\n-- \nZack Brown\n"},{"id":"13322","messageId":"7vacfcu7jy.fsf@assigned-by-dhcp.cox.net","threadId":"59","inReplyTo":"20051207145646.GA9207@tumblerings.org","subject":"Re: dotfile support","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-12-07T17:43:29Z","receivedAt":"2005-12-07T17:43:29Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Zack Brown writes:\n\n> What's the status of dotfile support? I can only find one thread that really\n> discusses the issue:\n>...\n> So that's my pitch: Leaving out dotfile support seems like it creates an\n> unnecessary limitation that eliminates some valid uses of git.\n\nValid argument, and resolved thusly quite some time ago, with\ncommit 320d3a1b1aa04d75f0aaff3cc7cf582e144a84c6 on May 24th\n2005.\n\nYou probably have missed it because unfortunately this commit\nhappened after the latest issue of git traffic ;-).\n"},{"id":"13325","messageId":"20051207181924.GA21343@tumblerings.org","threadId":"59","inReplyTo":"7vacfcu7jy.fsf@assigned-by-dhcp.cox.net","subject":"Re: dotfile support","fromName":"Zack Brown","fromEmail":"zbrown@tumblerings.org","sentAt":"2005-12-07T18:19:24Z","receivedAt":"2005-12-07T18:19:24Z","isPatch":false,"sender":{"key":"zbrown@tumblerings.org","avatar":null},"body":"On Wed, Dec 07, 2005 at 09:43:29AM -0800, Junio C Hamano wrote:\n> Zack Brown writes:\n> \n> > What's the status of dotfile support? I can only find one thread that really\n> > discusses the issue:\n> >...\n> > So that's my pitch: Leaving out dotfile support seems like it creates an\n> > unnecessary limitation that eliminates some valid uses of git.\n> \n> Valid argument, and resolved thusly quite some time ago, with\n> commit 320d3a1b1aa04d75f0aaff3cc7cf582e144a84c6 on May 24th\n> 2005.\n> \n> You probably have missed it because unfortunately this commit\n> happened after the latest issue of git traffic ;-).\n\nActually I've started including summaries of git list threads in Kernel Traffic\nas well, for the past few issues. :)\n\nBe well,\nZack\n\n> \n\n-- \nZack Brown\n"},{"id":"13328","messageId":"7vk6egram5.fsf@assigned-by-dhcp.cox.net","threadId":"59","inReplyTo":"20051207181924.GA21343@tumblerings.org","subject":"Re: dotfile support","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-12-07T19:05:38Z","receivedAt":"2005-12-07T19:05:38Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Zack Brown writes:\n\n>> You probably have missed it because unfortunately this commit\n>> happened after the latest issue of git traffic ;-).\n>\n> Actually I've started including summaries of git list threads\n> in Kernel Traffic as well, for the past few issues. :)\n\nI was just trying to be funny. My apologies.\n\nI do read kernel-traffic and appreciate your helping us keep\ncurrent very much.\n"},{"id":"13335","messageId":"20051207215156.GK22159@pasky.or.cz","threadId":"59","inReplyTo":"20051207161130.GA10924@tumblerings.org","subject":"Re: dotfile support","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-12-07T21:51:56Z","receivedAt":"2005-12-07T21:51:56Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Wed, Dec 07, 2005 at 05:11:30PM CET, I got a letter\nwhere Zack Brown said that...\n> So my question is, why does cg-init ignore dotfiles within the directory when it\n> first initializes the repository?\n\nPrecisely for Linus' reasons - by default, I believe your VCS shouldn't\ncare about your hidden files, because they are hidden, and probably not\ncontent but kind of meta-content - the exception is .gitignore, but you\ncan add more even on cg-init time. I have to admit that cg-init\ndocumentation wasn't sufficiently clear about this autoignoring stuff,\nI've tried to improve that now, and cg-init will warn you (post hoc)\nthat it autoignored some files.\n\nThanks,\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"},{"id":"13341","messageId":"4397829F.1020609@zytor.com","threadId":"59","inReplyTo":"20051207145646.GA9207@tumblerings.org","subject":"Re: dotfile support","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2005-12-08T00:47:27Z","receivedAt":"2005-12-08T00:47:27Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Zack Brown wrote:\n> Hi,\n> \n> What's the status of dotfile support?\n\nWorks fine for me; I now maintain my shell config files in git.\n\n\t-hpa\n"}]}