{"thread":{"id":"23614","subject":"Metadata and checkin file date","startedAt":"2010-04-27T05:23:57Z","lastAt":"2010-04-27T21:25:15Z","messageCount":10,"participants":["Gerhard Wiesinger","Andreas Ericsson","Jakub Narebski"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"140473","messageId":"alpine.LFD.2.00.1004270719320.17234@bbs.intern","threadId":"23614","inReplyTo":null,"subject":"Metadata and checkin file date","fromName":"Gerhard Wiesinger","fromEmail":"lists@wiesinger.com","sentAt":"2010-04-27T05:23:57Z","receivedAt":"2010-04-27T05:23:57Z","isPatch":false,"sender":{"key":"lists@wiesinger.com","avatar":null},"body":"Hello,\n\nI'm new to git and I'm looking for the following features:\n1.) Metadata for\n   a.) directory versioning (e.g. add/rm, mv)\n   b.) rights (basic: chmod, chow, chgrp, extended: extended attributes \nlike ACLs and selinux), necessary for versioning e.g. /etc\n2.) Original file dates (checkin date) on clone and pull (and not checkout \ndate)\n\nIs this possible? Any plans if missing?\n\nThnx.\n\nCiao,\nGerhard\n\n--\nhttp://www.wiesinger.com/\n"},{"id":"140485","messageId":"4BD6ACEF.1040909@op5.se","threadId":"23614","inReplyTo":"alpine.LFD.2.00.1004270719320.17234@bbs.intern","subject":"Re: Metadata and checkin file date","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2010-04-27T09:22:55Z","receivedAt":"2010-04-27T09:22:55Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"On 04/27/2010 07:23 AM, Gerhard Wiesinger wrote:\n> Hello,\n> \n> I'm new to git and I'm looking for the following features:\n> 1.) Metadata for\n> a.) directory versioning (e.g. add/rm, mv)\n\nIf you're talking about empty directories, that feature doesn't\nexist and I can't imagine why you'd want it to. If you'd care to\nexplain why you want it, I'm sure we can find a different way of\nachieving your goal.\n\n> b.) rights (basic: chmod, chow, chgrp, extended: extended attributes \n> like ACLs and selinux), necessary for versioning e.g. /etc\n\nSounds like you want a backup-program. Some projects have been\naimed towards this goal already. I'm sure google can provide\nmore information. AFAIR, most of them work with two hook-scripts\nthat update a regular file with the meta-data of all tracked\nfiles. This makes committing and checking out slower than it\nwould otherwise be, but since it's doing more I suppose that's\nto be expected.\n\nAdding it to core git would mean re-designing git's basic data\nmodel, which is obviously not something we're about to do on\na whim.\n\n> 2.) Original file dates (checkin date) on clone and pull (and not \n> checkout date)\n> \n\nI expect the solutions that work for 1b will also have this\n\"feature\", or that it will be easy to patch for it. For a\nsource code management system though, this is a very bad\nidea indeed since it messes with the fundamental rules of\nbuilding; A changed file must be rebuilt.\n\nSeeing as this would also require a major change in git's\ndata model, this is another of those changes that I doubt\nwill be supported in the git core in the foreseeable future.\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n\nConsidering the successes of the wars on alcohol, poverty, drugs and\nterror, I think we should give some serious thought to declaring war\non peace.\n"},{"id":"140486","messageId":"m3sk6hck8b.fsf@localhost.localdomain","threadId":"23614","inReplyTo":"alpine.LFD.2.00.1004270719320.17234@bbs.intern","subject":"Re: Metadata and checkin file date","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2010-04-27T09:35:00Z","receivedAt":"2010-04-27T09:35:00Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Gerhard Wiesinger <lists@wiesinger.com> writes:\n\n> Hello,\n> \n> I'm new to git and I'm looking for the following features:\n> 1.) Metadata for\n>    a.) directory versioning (e.g. add/rm, mv)\n>    b.) rights (basic: chmod, chow, chgrp, extended: extended\n> attributes like ACLs and selinux), necessary for versioning e.g. /etc\n> 2.) Original file dates (checkin date) on clone and pull (and not\n> checkout date)\n> \n> Is this possible? Any plans if missing?\n\nGit is distributed version control system (DVCS), not a backup system.\nIt is used mainly for distributed development of programs.  Therefore\nit supports natively only those parts of metadata that make sense for\nVCS, namely symlinks (with workaround for filesystems that do not have\nsupport for symbolic links) and the executable permission for files.\n\nFile ownership does not make sense for VCS, as other people that clone\nyour repository do not have the same set of users that you have, and\nmight not have the same set of groups that you have.  Neverthemind that\ntheir filesystem might not support notion of file ownership, not only\ndo not have support for extended attributes and the like.\n\nIf you really, really need this, you can use additional tools to\npreserve metadata, like Metastore or git-cache-meta, or even ready\ntools that use Git as bckend like IsiSetup or bup (well, bup use\ngit package format, not git itself...), see this Git Wiki page:\nhttps://git.wiki.kernel.org/index.php/InterfacesFrontendsAndTools\n\nHTH (Hope That Helps)\n-- \nJakub Narebski\nPoland\n"},{"id":"140533","messageId":"alpine.LFD.2.00.1004272111540.5630@bbs.intern","threadId":"23614","inReplyTo":"4BD6ACEF.1040909@op5.se","subject":"Re: Metadata and checkin file date","fromName":"Gerhard Wiesinger","fromEmail":"lists@wiesinger.com","sentAt":"2010-04-27T19:38:26Z","receivedAt":"2010-04-27T19:38:26Z","isPatch":false,"sender":{"key":"lists@wiesinger.com","avatar":null},"body":"On Tue, 27 Apr 2010, Andreas Ericsson wrote:\n\n> On 04/27/2010 07:23 AM, Gerhard Wiesinger wrote:\n>> Hello,\n>>\n>> I'm new to git and I'm looking for the following features:\n>> 1.) Metadata for\n>> a.) directory versioning (e.g. add/rm, mv)\n>\n> If you're talking about empty directories, that feature doesn't\n> exist and I can't imagine why you'd want it to. If you'd care to\n> explain why you want it, I'm sure we can find a different way of\n> achieving your goal.\n\nGit focuses on content but I think git should also focus on \nmetadata. For example restructuring source code moves (git mv \nfile1.c file2.c, git mv dir1 dir2) should be documented also in the \nrepository like e.g. subversion and commercial SCM like clearcase do. \nOtherwise we are on \"CVS\" level.\n\nEmpty directories is a special case and sometimes you need just versioned \nempty directies.\n\n>> b.) rights (basic: chmod, chow, chgrp, extended: extended attributes\n>> like ACLs and selinux), necessary for versioning e.g. /etc\n>\n> Sounds like you want a backup-program. Some projects have been\n> aimed towards this goal already. I'm sure google can provide\n> more information. AFAIR, most of them work with two hook-scripts\n> that update a regular file with the meta-data of all tracked\n> files. This makes committing and checking out slower than it\n> would otherwise be, but since it's doing more I suppose that's\n> to be expected.\n>\n> Adding it to core git would mean re-designing git's basic data\n> model, which is obviously not something we're about to do on\n> a whim.\n\nNo, I'm NOT looking for a backup program. Every admin has the problem of \nversioning config files (for example /etc). Versioning of config files \nmakes sense because one can track the changes and e.g. correlate to \nproblems. A backup program doesn't have features like history, committer \nand comments on file changes. Therefore git would be a perfect tool also for \nversioning configuration. (Software development doesn't end with the build \nbut typically also has deployment&configuration issues).\n\nAnd when you think about a destroyed machine where you want to \nget your versioned configuration you also want to get the right \npermissions therefore. Otherwise you have for sure a security leak or a \nnon working machine.\n\nYou can also think on machines where the same config should be used and \ntracked.\n\n>> 2.) Original file dates (checkin date) on clone and pull (and not\n>> checkout date)\n>>\n>\n> I expect the solutions that work for 1b will also have this\n> \"feature\", or that it will be easy to patch for it. For a\n> source code management system though, this is a very bad\n> idea indeed since it messes with the fundamental rules of\n> building; A changed file must be rebuilt.\n>\n> Seeing as this would also require a major change in git's\n> data model, this is another of those changes that I doubt\n> will be supported in the git core in the foreseeable future.\n\nI agree that a changed file must be rebuilt but in the normal \"forward\" \ncases that's also guaranteed with commit dates as they are \"later\". But \nwhen you get an old version you can't assume anything (e.g. dependencies \nhave completly changed, even file structure) and therefore only a clean \nbuild (e.g. make clean) is IHMO valid.\n\nI think git already has the commit date for the revision the user wants. \nTherefore only a call to \"set_date_and_time\" is necessary when a file \nis touched (e.g. by switch --use-commit-timestamps, environment variable \nor by config item). Therefor this should IHMO be easy to implement without \nany metadata changes.\n\nThnx.\n\nCiao,\nGerhard\n"},{"id":"140534","messageId":"alpine.LFD.2.00.1004272139080.5630@bbs.intern","threadId":"23614","inReplyTo":"m3sk6hck8b.fsf@localhost.localdomain","subject":"Re: Metadata and checkin file date","fromName":"Gerhard Wiesinger","fromEmail":"lists@wiesinger.com","sentAt":"2010-04-27T19:41:56Z","receivedAt":"2010-04-27T19:41:56Z","isPatch":false,"sender":{"key":"lists@wiesinger.com","avatar":null},"body":"On Tue, 27 Apr 2010, Jakub Narebski wrote:\n\n> Gerhard Wiesinger <lists@wiesinger.com> writes:\n>\n>> Hello,\n>>\n>> I'm new to git and I'm looking for the following features:\n>> 1.) Metadata for\n>>    a.) directory versioning (e.g. add/rm, mv)\n>>    b.) rights (basic: chmod, chow, chgrp, extended: extended\n>> attributes like ACLs and selinux), necessary for versioning e.g. /etc\n>> 2.) Original file dates (checkin date) on clone and pull (and not\n>> checkout date)\n>>\n>> Is this possible? Any plans if missing?\n>\n> Git is distributed version control system (DVCS), not a backup system.\n> It is used mainly for distributed development of programs.  Therefore\n> it supports natively only those parts of metadata that make sense for\n> VCS, namely symlinks (with workaround for filesystems that do not have\n> support for symbolic links) and the executable permission for files.\n>\n> File ownership does not make sense for VCS, as other people that clone\n> your repository do not have the same set of users that you have, and\n> might not have the same set of groups that you have.  Neverthemind that\n> their filesystem might not support notion of file ownership, not only\n> do not have support for extended attributes and the like.\n\nI would suggest that only with special switches like --preserve-chmod \n--preserver-owner --preserve-group , etc. where one can guarantee user, \ngroups, etc. See also my second post for arguments.\n\n> If you really, really need this, you can use additional tools to\n> preserve metadata, like Metastore or git-cache-meta, or even ready\n> tools that use Git as bckend like IsiSetup or bup (well, bup use\n> git package format, not git itself...), see this Git Wiki page:\n> https://git.wiki.kernel.org/index.php/InterfacesFrontendsAndTools\n>\n\nWill have a look at them.\n\nThnx.\n\nCiao,\nGerhard\n\n--\nhttp://www.wiesinger.com/\n"},{"id":"140535","messageId":"4BD73F64.1070604@op5.se","threadId":"23614","inReplyTo":"alpine.LFD.2.00.1004272111540.5630@bbs.intern","subject":"Re: Metadata and checkin file date","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2010-04-27T19:47:48Z","receivedAt":"2010-04-27T19:47:48Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"On 04/27/2010 09:38 PM, Gerhard Wiesinger wrote:\n> On Tue, 27 Apr 2010, Andreas Ericsson wrote:\n> \n>> On 04/27/2010 07:23 AM, Gerhard Wiesinger wrote:\n>>> Hello,\n>>>\n>>> I'm new to git and I'm looking for the following features:\n>>> 1.) Metadata for\n>>> a.) directory versioning (e.g. add/rm, mv)\n>>\n>> If you're talking about empty directories, that feature doesn't\n>> exist and I can't imagine why you'd want it to. If you'd care to\n>> explain why you want it, I'm sure we can find a different way of\n>> achieving your goal.\n> \n> Git focuses on content but I think git should also focus on metadata. \n> For example restructuring source code moves (git mv file1.c file2.c, git \n> mv dir1 dir2) should be documented also in the repository like e.g. \n> subversion and commercial SCM like clearcase do. Otherwise we are on \n> \"CVS\" level.\n> \n> Empty directories is a special case and sometimes you need just \n> versioned empty directies.\n> \n\nThis has been discussed to death several times before on this mailing\nlist. Browse the archives. There haven't been any new arguments the\nlast 14 times it came up, so I doubt you'll be able to come up with\na single good reason to track file renames explicitly.\n\n>>> b.) rights (basic: chmod, chow, chgrp, extended: extended attributes\n>>> like ACLs and selinux), necessary for versioning e.g. /etc\n>>\n>> Sounds like you want a backup-program. Some projects have been\n>> aimed towards this goal already. I'm sure google can provide\n>> more information. AFAIR, most of them work with two hook-scripts\n>> that update a regular file with the meta-data of all tracked\n>> files. This makes committing and checking out slower than it\n>> would otherwise be, but since it's doing more I suppose that's\n>> to be expected.\n>>\n>> Adding it to core git would mean re-designing git's basic data\n>> model, which is obviously not something we're about to do on\n>> a whim.\n> \n> No, I'm NOT looking for a backup program. Every admin has the problem of \n> versioning config files (for example /etc). Versioning of config files \n> makes sense because one can track the changes and e.g. correlate to \n> problems. A backup program doesn't have features like history, committer \n> and comments on file changes. Therefore git would be a perfect tool also \n> for versioning configuration. (Software development doesn't end with the \n> build but typically also has deployment&configuration issues).\n> \n\nRight. So you want a *fancy* backup program and not just any random\nbackup solution. There are solutions for this. Someone else already\nmentioned them elsewhere in this thread, so I'll refrain from further\ncomments on this.\n\nIn short: What you want can be (and has been) done, but it's written\nas addons and not integral parts of git.\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n\nConsidering the successes of the wars on alcohol, poverty, drugs and\nterror, I think we should give some serious thought to declaring war\non peace.\n"},{"id":"140537","messageId":"alpine.LFD.2.00.1004272152190.11216@bbs.intern","threadId":"23614","inReplyTo":"4BD73F64.1070604@op5.se","subject":"Re: Metadata and checkin file date","fromName":"Gerhard Wiesinger","fromEmail":"lists@wiesinger.com","sentAt":"2010-04-27T20:00:20Z","receivedAt":"2010-04-27T20:00:20Z","isPatch":false,"sender":{"key":"lists@wiesinger.com","avatar":null},"body":"On Tue, 27 Apr 2010, Andreas Ericsson wrote:\n\n> On 04/27/2010 09:38 PM, Gerhard Wiesinger wrote:\n>> On Tue, 27 Apr 2010, Andreas Ericsson wrote:\n>>\n>>> On 04/27/2010 07:23 AM, Gerhard Wiesinger wrote:\n>>>> Hello,\n>>>>\n>>>> I'm new to git and I'm looking for the following features:\n>>>> 1.) Metadata for\n>>>> a.) directory versioning (e.g. add/rm, mv)\n>>>\n>>> If you're talking about empty directories, that feature doesn't\n>>> exist and I can't imagine why you'd want it to. If you'd care to\n>>> explain why you want it, I'm sure we can find a different way of\n>>> achieving your goal.\n>>\n>> Git focuses on content but I think git should also focus on metadata.\n>> For example restructuring source code moves (git mv file1.c file2.c, git\n>> mv dir1 dir2) should be documented also in the repository like e.g.\n>> subversion and commercial SCM like clearcase do. Otherwise we are on\n>> \"CVS\" level.\n>>\n>> Empty directories is a special case and sometimes you need just\n>> versioned empty directies.\n>>\n>\n> This has been discussed to death several times before on this mailing\n> list. Browse the archives. There haven't been any new arguments the\n> last 14 times it came up, so I doubt you'll be able to come up with\n> a single good reason to track file renames explicitly.\n\nAs it pops up that often by git users I think it is an issue which \nshouldn't be ignored as users should be king :-)\n\n>>>> b.) rights (basic: chmod, chow, chgrp, extended: extended attributes\n>>>> like ACLs and selinux), necessary for versioning e.g. /etc\n>>>\n>>> Sounds like you want a backup-program. Some projects have been\n>>> aimed towards this goal already. I'm sure google can provide\n>>> more information. AFAIR, most of them work with two hook-scripts\n>>> that update a regular file with the meta-data of all tracked\n>>> files. This makes committing and checking out slower than it\n>>> would otherwise be, but since it's doing more I suppose that's\n>>> to be expected.\n>>>\n>>> Adding it to core git would mean re-designing git's basic data\n>>> model, which is obviously not something we're about to do on\n>>> a whim.\n>>\n>> No, I'm NOT looking for a backup program. Every admin has the problem of\n>> versioning config files (for example /etc). Versioning of config files\n>> makes sense because one can track the changes and e.g. correlate to\n>> problems. A backup program doesn't have features like history, committer\n>> and comments on file changes. Therefore git would be a perfect tool also\n>> for versioning configuration. (Software development doesn't end with the\n>> build but typically also has deployment&configuration issues).\n>>\n>\n> Right. So you want a *fancy* backup program and not just any random\n> backup solution. There are solutions for this. Someone else already\n> mentioned them elsewhere in this thread, so I'll refrain from further\n> comments on this.\n>\n> In short: What you want can be (and has been) done, but it's written\n> as addons and not integral parts of git.\n\nA first quick look on them: They are only a workaround to the real \nproblem. For example subversion therefore has generic properties which \nalso can be user defined (e.g. svn propset/propget) and I think such a \nconcept should also be integrated part of git.\n\nOnly my 2 cents making git (one of the SCM where I think it is very \npowerful and has also potential in the future) even better than \ncompetition.\n\nCiao,\nGerhard\n\n--\nhttp://www.wiesinger.com/\n"},{"id":"140552","messageId":"201004272255.47394.jnareb@gmail.com","threadId":"23614","inReplyTo":"alpine.LFD.2.00.1004272139080.5630@bbs.intern","subject":"Re: Metadata and checkin file date","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2010-04-27T20:55:47Z","receivedAt":"2010-04-27T20:55:47Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Tue, 27 Apr 2010, Gerhard Wiesinger wrote:\n> On Tue, 27 Apr 2010, Jakub Narebski wrote:\n>> Gerhard Wiesinger <lists@wiesinger.com> writes:\n>>\n>>> I'm new to git and I'm looking for the following features:\n>>> 1.) Metadata for\n>>>    a.) directory versioning (e.g. add/rm, mv)\n>>>    b.) rights (basic: chmod, chow, chgrp, extended: extended\n>>> attributes like ACLs and selinux), necessary for versioning e.g. /etc\n>>> 2.) Original file dates (checkin date) on clone and pull (and not\n>>> checkout date)\n>>>\n>>> Is this possible? Any plans if missing?\n>>\n>> Git is distributed version control system (DVCS), not a backup system.\n>> It is used mainly for distributed development of programs.  Therefore\n>> it supports natively only those parts of metadata that make sense for\n>> VCS, namely symlinks (with workaround for filesystems that do not have\n>> support for symbolic links) and the executable permission for files.\n>>\n>> File ownership does not make sense for VCS, as other people that clone\n>> your repository do not have the same set of users that you have, and\n>> might not have the same set of groups that you have.  Neverthemind that\n>> their filesystem might not support notion of file ownership, not only\n>> do not have support for extended attributes and the like.\n> \n> I would suggest that only with special switches like --preserve-chmod \n> --preserver-owner --preserve-group , etc. where one can guarantee user, \n> groups, etc. See also my second post for arguments.\n\nDo *one* thing, and do it well.\n\nNote that in 'tree' object (used to represent directories, and holding\nnames and executable permission of files) there is simply no place for\nfull ownership, for timestamp(s), for extended attributes.  And changing\nrepository format for such minor fringe usage is out of the question for\nGit.\n\nSo you would have to use some .gitmetadata file to store additional\nmetadata.  And then you can utilize hooks mechanism, i.e. add this\nfunctionality to extra tool like etckeeper or IsiSetup, just like patch\nmanagement is done with extra tools like StGit, Guilt or TopGit.\n\n>> If you really, really need this, you can use additional tools to\n>> preserve metadata, like Metastore or git-cache-meta, or even ready\n>> tools that use Git as bckend like IsiSetup or bup (well, bup use\n>> git package format, not git itself...), see this Git Wiki page:\n>> https://git.wiki.kernel.org/index.php/InterfacesFrontendsAndTools\n> \n> Will have a look at them.\n\n-- \nJakub Narebski\nPoland\n"},{"id":"140553","messageId":"m3och4d27t.fsf@localhost.localdomain","threadId":"23614","inReplyTo":"4BD73F64.1070604@op5.se","subject":"Re: Metadata and checkin file date","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2010-04-27T21:18:54Z","receivedAt":"2010-04-27T21:18:54Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Andreas Ericsson <ae@op5.se> writes:\n> On 04/27/2010 09:38 PM, Gerhard Wiesinger wrote:\n>> On Tue, 27 Apr 2010, Andreas Ericsson wrote:\n>>> On 04/27/2010 07:23 AM, Gerhard Wiesinger wrote:\n>>>>\n>>>> I'm new to git and I'm looking for the following features:\n>>>> 1.) Metadata for\n>>>> a.) directory versioning (e.g. add/rm, mv)\n>>>\n>>> If you're talking about empty directories, that feature doesn't\n>>> exist and I can't imagine why you'd want it to. If you'd care to\n>>> explain why you want it, I'm sure we can find a different way of\n>>> achieving your goal.\n>> \n>> Git focuses on content but I think git should also focus on metadata. \n>> For example restructuring source code moves (git mv file1.c file2.c, git \n>> mv dir1 dir2) should be documented also in the repository like e.g. \n>> subversion and commercial SCM like clearcase do. Otherwise we are on \n>> \"CVS\" level.\n\n\"git mv file1.c file2.c\" works in practice thanks to heuristic\nsimilarity based rename detection that git uses.  (Note that it might\nnot work in simplistic tests.)\n\n\"git mv dir1 dir2\" works via _file_ rename detection, except for one\nuse case, namely when on one branch one does \"git mv dir1 dir2\", \nand in other branch one does \"git add dir1/file.c\" (new file in old\ndirectory name).  See also below.\n\n>> Empty directories is a special case and sometimes you need just \n>> versioned empty directies.\n> \n> This has been discussed to death several times before on this mailing\n> list. Browse the archives. There haven't been any new arguments the\n> last 14 times it came up, so I doubt you'll be able to come up with\n> a single good reason to track file renames explicitly.\n\nThere are three issues conflated here:\n\n1. Rename tracking.  This is no go.  The only idea that have hint of\n   being perhaps possibly accepted is recording resolutions of\n   tree-level conflict in git-rerere2 cache.\n\n2. Wholesame directory rename detection.  Possible, there were even\n   some proof of concept patches send to git mailing list, but it\n   didn't get merged in.  Would need to be resurrected, but this is\n   not easy task.\n\n3. Support for versioning empty directories.  Possible, but it would\n   require extending index (the staging area one) to be able to hold\n   not only files but also directories.  Not very easy.\n\n   Current workaround: empty .gitignore / .keepme files.\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"140554","messageId":"m3k4rsd1x2.fsf@localhost.localdomain","threadId":"23614","inReplyTo":"alpine.LFD.2.00.1004272152190.11216@bbs.intern","subject":"Re: Metadata and checkin file date","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2010-04-27T21:25:15Z","receivedAt":"2010-04-27T21:25:15Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Gerhard Wiesinger <lists@wiesinger.com> writes:\n> On Tue, 27 Apr 2010, Andreas Ericsson wrote:\n>> On 04/27/2010 09:38 PM, Gerhard Wiesinger wrote:\n>>> On Tue, 27 Apr 2010, Andreas Ericsson wrote:\n>>>> On 04/27/2010 07:23 AM, Gerhard Wiesinger wrote:\n\n>>>>> b.) rights (basic: chmod, chow, chgrp, extended: extended attributes\n>>>>> like ACLs and selinux), necessary for versioning e.g. /etc\n>>>>\n>>>> Sounds like you want a backup-program. Some projects have been\n>>>> aimed towards this goal already. [...]. AFAIR, most of them work\n>>>> with two hook-scripts that update a regular file with the\n>>>> meta-data of all tracked files. [...]\n>>>>\n>>>> Adding it to core git would mean re-designing git's basic data\n>>>> model, which is obviously not something we're about to do on\n>>>> a whim.\n>>>\n>>> No, I'm NOT looking for a backup program. Every admin has the problem of\n>>> versioning config files (for example /etc). Versioning of config files\n>>> makes sense because one can track the changes and e.g. correlate to\n>>> problems. A backup program doesn't have features like history, committer\n>>> and comments on file changes. Therefore git would be a perfect tool also\n>>> for versioning configuration. (Software development doesn't end with the\n>>> build but typically also has deployment&configuration issues).\n\nSee IsiSetup, etckeeper and other such tools.\n\n[...]\n>> In short: What you want can be (and has been) done, but it's written\n>> as addons and not integral parts of git.\n> \n> A first quick look on them: They are only a workaround to the real\n> problem. For example subversion therefore has generic properties which\n> also can be user defined (e.g. svn propset/propget) and I think such a\n> concept should also be integrated part of git.\n> \n> Only my 2 cents making git (one of the SCM where I think it is very\n> powerful and has also potential in the future) even better than\n> competition.\n\nActually using *properties* is one of MIS-designs of Subversion.\nStoring generic sh*t in repository is not a good idea either.\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"}]}