{"thread":{"id":"27028","subject":"Tracking file metadata in git -- fix metastore or enhance git?","startedAt":"2011-04-07T19:16:19Z","lastAt":"2011-12-20T00:55:55Z","messageCount":19,"participants":["Richard Hartmann","Thorsten Glaser","Michael J Gruber","Jonathan Nieder","Chris Webb","Junio C Hamano","johnnyutahh"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"165377","messageId":"BANLkTikkb3DUOtP9NUtNMNV5Z+oJ7AFHfg@mail.gmail.com","threadId":"27028","inReplyTo":null,"subject":"Tracking file metadata in git -- fix metastore or enhance git?","fromName":"Richard Hartmann","fromEmail":"richih.mailinglist@gmail.com","sentAt":"2011-04-07T19:16:19Z","receivedAt":"2011-04-07T19:16:19Z","isPatch":false,"sender":{"key":"richih.mailinglist@gmail.com","avatar":"https://avatars.githubusercontent.com/u/754723?v=4"},"body":"Hi all,\n\n\nas you know, it's not possible to track metadata like mtime etc via\ngit natively. metastore exists, but its binary storage format is\nmerge-unfriendly. The author knows and acknowledges this but lacks the\ntime to fix it.\n\nWe might try and fix up metastore to use ASCII with BASE64 for xattr\netc instead of the current binary format. metastore supports versioned\nstores so it will handle this gracefully. Before going down this path,\nI wanted to ask if anyone would be interested to implement this in git\ndirectly. Obviously, an optional and native way is vastly preferable\nto a third-party tool. Both for reasons of potential bit-rot and more\nusers. Yet, we lack the confidence to do this in git directly\nourselves.\n\nIf this is implemented in git, the type(s) of metadata to track should\nbe fine-grained and fully optional, of course.\n\n\nAny and all feedback appreciated,\nRichard\n"},{"id":"165380","messageId":"Pine.BSM.4.64L.1104071923580.4692@herc.mirbsd.org","threadId":"27028","inReplyTo":"BANLkTikkb3DUOtP9NUtNMNV5Z+oJ7AFHfg@mail.gmail.com","subject":"Re: Tracking file metadata in git -- fix metastore or enhance git?","fromName":"Thorsten Glaser","fromEmail":"tg@mirbsd.de","sentAt":"2011-04-07T19:27:57Z","receivedAt":"2011-04-07T19:27:57Z","isPatch":false,"sender":{"key":"tg@mirbsd.de","avatar":"https://gravatar.com/avatar/e4bb7217fcb56def9c570cc3803933454cebf7617d95e8fa82d3b56141c53413?d=mp&s=160"},"body":"Richard Hartmann dixit:\n\n>git natively. metastore exists, but its binary storage format is\n\nAccording to the documentation, metastore supports saving/restoring\nPOSIX Extended Attributes (however I got EOPNOTSUPP trying to setfacl\nand setxattr, so I couldn’t verify the claim). It does *not* however\ntrack the stuff visible using lsattr(1) on ext2fs.\n\nPersonally, I think this should definitively be tracked in git, not\nin extra files (like “ EA DATA. SF” in OS/2) managed with external\ntools (reminds me too much of things like umsdos and Rock Ridge as\nwell). Support needs not be part of core git, especially restoring\ncan be dangerous (consider SELinux), plus it’s very platform and\nfilesystem dependent, but seeing that people seem to want to use\ngit for keeping their /etc (I use RCS, myself, but volunteered my\nC skill to change metastore if it needs be) there is definitively\na market for having it there, in a standardised manner.\n\nbye,\n//mirabilos\n-- \nFWIW, I'm quite impressed with mksh interactively. I thought it was much\n*much* more bare bones. But it turns out it beats the living hell out of\nksh93 in that respect. I'd even consider it for my daily use if I hadn't\nwasted half my life on my zsh setup. :-) -- Frank Terbeck in #!/bin/mksh\n"},{"id":"165392","messageId":"BANLkTink-c8JuxnMBCAmXiVwFkBxJrTucw@mail.gmail.com","threadId":"27028","inReplyTo":"Pine.BSM.4.64L.1104071923580.4692@herc.mirbsd.org","subject":"Re: Tracking file metadata in git -- fix metastore or enhance git?","fromName":"Richard Hartmann","fromEmail":"richih.mailinglist@gmail.com","sentAt":"2011-04-08T00:29:59Z","receivedAt":"2011-04-08T00:29:59Z","isPatch":false,"sender":{"key":"richih.mailinglist@gmail.com","avatar":"https://avatars.githubusercontent.com/u/754723?v=4"},"body":"On Thu, Apr 7, 2011 at 21:27, Thorsten Glaser wrote:\n\n> but seeing that people seem to want to use\n> git for keeping their /etc (I use RCS, myself, but volunteered my\n> C skill to change metastore if it needs be) there is definitively\n> a market for having it there, in a standardised manner.\n\netckeeper does exist and it's very useful.\n\n\nRichard\n"},{"id":"165415","messageId":"4D9EDCEA.9010903@drmicha.warpmail.net","threadId":"27028","inReplyTo":"BANLkTink-c8JuxnMBCAmXiVwFkBxJrTucw@mail.gmail.com","subject":"Re: Tracking file metadata in git -- fix metastore or enhance git?","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-04-08T10:01:14Z","receivedAt":"2011-04-08T10:01:14Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Richard Hartmann venit, vidit, dixit 08.04.2011 02:29:\n> On Thu, Apr 7, 2011 at 21:27, Thorsten Glaser wrote:\n> \n>> but seeing that people seem to want to use\n>> git for keeping their /etc (I use RCS, myself, but volunteered my\n>> C skill to change metastore if it needs be) there is definitively\n>> a market for having it there, in a standardised manner.\n> \n> etckeeper does exist and it's very useful.\n\nWhile I think there is some consensus not to have attribs (besides x) in\ncore git, contrib/ may be a good place.\n\nNote that etckeeper and metastore predate our notes feature. By now, a\nnotes tree is a perfect place to store meta information. You can attach\nnotes to blobs perfectly (see textconv-cache). That may be an option for\na reimplementation, depending on how you want the versioning of the\nfiles to be related with the versioning of the meta data.\n\nMichael\n"},{"id":"165438","messageId":"20110408185924.GA25840@elie","threadId":"27028","inReplyTo":"4D9EDCEA.9010903@drmicha.warpmail.net","subject":"Re: Tracking file metadata in git -- fix metastore or enhance git?","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-04-08T18:59:24Z","receivedAt":"2011-04-08T18:59:24Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nMichael J Gruber wrote:\n\n> Note that etckeeper and metastore predate our notes feature. By now, a\n> notes tree is a perfect place to store meta information. You can attach\n> notes to blobs perfectly (see textconv-cache). That may be an option for\n> a reimplementation, depending on how you want the versioning of the\n> files to be related with the versioning of the meta data.\n\nWouldn't that mean the same content couldn't have one owner in one\ncommit and a different owner in another commit?\n\nI think the most native-looking way to store metadata associated to\npaths is .gitattributes. It also has the nice feature of allowing a\nsingle attribute to apply to multiple files. But the tools for\nlooking them up (e.g., git check-attr) do not get much use yet so they\nprobably could use a lot of improvement.\n"},{"id":"165439","messageId":"Pine.BSM.4.64L.1104081903550.22999@herc.mirbsd.org","threadId":"27028","inReplyTo":"20110408185924.GA25840@elie","subject":"Re: Tracking file metadata in git -- fix metastore or enhance git?","fromName":"Thorsten Glaser","fromEmail":"tg@mirbsd.de","sentAt":"2011-04-08T19:05:31Z","receivedAt":"2011-04-08T19:05:31Z","isPatch":false,"sender":{"key":"tg@mirbsd.de","avatar":"https://gravatar.com/avatar/e4bb7217fcb56def9c570cc3803933454cebf7617d95e8fa82d3b56141c53413?d=mp&s=160"},"body":"Jonathan Nieder dixit:\n\n>I think the most native-looking way to store metadata associated to\n>paths is .gitattributes. It also has the nice feature of allowing a\n>single attribute to apply to multiple files.\n\nEh, no. Think of extended attributes like, say, NTFS Resource Forks.\nThey’re just different “lines” into the “plane” a file can be, if\nyou excuse the metapher. (All parallel, of course.) They are just\nanother facet of each file.\n\nbye,\n//mirabilos\n-- \n22:20⎜ The crazy that persists in his craziness becomes a master\n22:21⎜ And the distance between the craziness and geniality is\nonly measured by the success 18:35⎜ \"Psychotics are consistently\ninconsistent. The essence of sanity is to be inconsistently inconsistent\n"},{"id":"165444","messageId":"20110408194548.GA26094@elie","threadId":"27028","inReplyTo":"Pine.BSM.4.64L.1104081903550.22999@herc.mirbsd.org","subject":"Re: Tracking file metadata in git -- fix metastore or enhance git?","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-04-08T19:45:48Z","receivedAt":"2011-04-08T19:45:48Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Thorsten Glaser wrote:\n> Jonathan Nieder dixit:\n\n>> I think the most native-looking way to store metadata associated to\n>> paths is .gitattributes. It also has the nice feature of allowing a\n>> single attribute to apply to multiple files.\n>\n> Eh, no. Think of extended attributes like, say, NTFS Resource Forks.\n> They’re just different “lines” into the “plane” a file can be, if\n> you excuse the metapher. (All parallel, of course.)\n\nDo you mean no, it doesn't have that feature? ;-)\n\nEach git commit (try it with \"git cat-file commit HEAD) looks like so:\n\n\ttree \n\tparent \n\tparent \n\t...\n\tauthor \n\tcommitter \n\tencoding \n\n\t\n\nWhere could one sneak in some per-path metadata?\n\n - as new header fields after \"encoder\" (teaching git fsck, git commit\n --amend, and so on about it)? That can work but it would slow down\n operations not interested in this metadata. It is best not to have\n O(number of paths) header fields.\n\n - in the change description? Yes, that can work, too, and it doesn't\n even require changing the commit format.\n\n - a new header field pointing to another object? That is possible as\n a last resort.\n\nAnyway, filenames and associated content are not what commits are\nabout; commits are just nodes in a revision graph, with trees representing\nthe tracked trees.\n\nOkay, so what about the trees?\n\n\t SP NUL \n\t...\n\nWhere can we sneak something in?\n\n - use a currently invalid ? No, tracking metadata is probably\n not worth breaking old git clients.\n - use an invalid object name? No (for the same reason).\n - use a special filename? Then old git clients will treat the file\n as a regular file, so they still get access to the data.\n\nSo you see, using ordinary files (whether called .gitattributes or\nfoo.c.ntfs-resource-fork) to track this extra data makes a lot of\nsense.\n\nNow Michael mentioned an alternative, which is to store this\ninformation in separate objects. That way, you could push your\nhistory without the extra metadata, you could edit the metadata\nwithout changing the commit names of the history, separately\ngarbage-collect metadata you're not interested in, etc. If that is\nyour goal, then \"git notes\" is exactly the right solution.\n\n> They are just\n> another facet of each file.\n\nSure, like the atime, the inode number, the uid of the user who wrote\nthem, and the model number of the disk used to store it.\n\nOh, you mean they're _relevant_ facets? Yes, that's believable,\nthough I suspect that's only going to sometimes be the case. So the\noperator should say \"yes, I'm interested in tracking this extra\ninformation\". To summarize the above, some ways this could work\nbehind the scenes:\n\n * dotfiles with metadata;\n\n * a Makefile to install files with metadata (i.e., the \"source\"\n consists of plain files, while the \"build product\" has the\n specified metadata);\n\n * something else. Hopefully the above explains the relevant\n constraints so you can surprise us.\n\nHope that helps.\nJonathan\n"},{"id":"165448","messageId":"Pine.BSM.4.64L.1104081955490.22999@herc.mirbsd.org","threadId":"27028","inReplyTo":"20110408194548.GA26094@elie","subject":"Re: Tracking file metadata in git -- fix metastore or enhance git?","fromName":"Thorsten Glaser","fromEmail":"tg@mirbsd.de","sentAt":"2011-04-08T19:58:21Z","receivedAt":"2011-04-08T19:58:21Z","isPatch":false,"sender":{"key":"tg@mirbsd.de","avatar":"https://gravatar.com/avatar/e4bb7217fcb56def9c570cc3803933454cebf7617d95e8fa82d3b56141c53413?d=mp&s=160"},"body":"Jonathan Nieder dixit:\n\n>Each git commit (try it with \"git cat-file commit HEAD) looks like so:\n[…]\n>So you see, using ordinary files […] makes a lot of\n>sense.\n\nTrue. I’d forgotten for a second that git is a stupid content\ntracker and confused it with a VCS. My bad. Your reasoning is\nof course sound. (I must admit I personally don’t have much\nexperience with git, other than losing a lot of data once.)\n\n>Now Michael mentioned an alternative, which is to store this\n>information in separate objects. That way, you could push your\n\nThis might be an alternative. RichiH, what are the requirements?\nI fear that the dotfile way will meet them better, considering\nthat they are versioned together, not separately, and what you\ntold me quickly about the idea.\n\nbye,\n//mirabilos\n-- \n13:47⎜ if i were omnipotent, i would divide by zero\n all day long ;)\n(thinking about http://lobacevski.tumblr.com/post/3260866481 by waga)\n"},{"id":"165458","messageId":"BANLkTi=3LPRzohnZStAogddpL5ZLehb97Q@mail.gmail.com","threadId":"27028","inReplyTo":"Pine.BSM.4.64L.1104081955490.22999@herc.mirbsd.org","subject":"Re: Tracking file metadata in git -- fix metastore or enhance git?","fromName":"Richard Hartmann","fromEmail":"richih.mailinglist@gmail.com","sentAt":"2011-04-08T21:23:29Z","receivedAt":"2011-04-08T21:23:29Z","isPatch":false,"sender":{"key":"richih.mailinglist@gmail.com","avatar":"https://avatars.githubusercontent.com/u/754723?v=4"},"body":"Ignoring any potentially flame-ish comments in the shared interest of\nfactual discussion and eventual consensus followed by progress; please\ndo the same :)\n\n\nOn Fri, Apr 8, 2011 at 21:58, Thorsten Glaser wrote:\n\n> This might be an alternative. RichiH, what are the requirements?\n\nThe main use case from my/our POV is to track mtime etc to maintain\nrelative and absolute differences which can be extremely useful for\ndata even if it's not needed for code files.\n\n\n> I fear that the dotfile way will meet them better, considering\n> that they are versioned together, not separately, and what you\n> told me quickly about the idea.\n\nPoints to consider:\n\n* In most cases I can think of, it would be preferable to track\nchanges in metadata along with the actual files.\n\n* It should be possible for other repositories to ignore this metadata.\n\n* I am not sure if notes are suitable for this. Using notes.displayRef\nto hide those notes is an option, but it would force everyone to set\nthis up locally. Else, it would be very spammy.\n\n* .gitattributes is too important to fill with potentially thousands\nof lines, imo. Using it to define what metadata should be stored would\nmake sense, though.\n\n* would a .gitmetadata make sense for storage? Alternatively, a\n.git/objects/??/*.metadata per object could make sense.\n\n\nThoughts?\nRichard\n"},{"id":"165481","messageId":"20110409081108.GE13750@arachsys.com","threadId":"27028","inReplyTo":"BANLkTi=3LPRzohnZStAogddpL5ZLehb97Q@mail.gmail.com","subject":"Re: Tracking file metadata in git -- fix metastore or enhance git?","fromName":"Chris Webb","fromEmail":"chris@arachsys.com","sentAt":"2011-04-09T08:11:08Z","receivedAt":"2011-04-09T08:11:08Z","isPatch":false,"sender":{"key":"chris@arachsys.com","avatar":"https://avatars.githubusercontent.com/u/299056?v=4"},"body":"Richard Hartmann writes:\n\n> * In most cases I can think of, it would be preferable to track\n> changes in metadata along with the actual files.\n> \n> * It should be possible for other repositories to ignore this metadata.\n> \n> * I am not sure if notes are suitable for this. Using notes.displayRef\n> to hide those notes is an option, but it would force everyone to set\n> this up locally. Else, it would be very spammy.\n> \n> * .gitattributes is too important to fill with potentially thousands\n> of lines, imo. Using it to define what metadata should be stored would\n> make sense, though.\n> \n> * would a .gitmetadata make sense for storage? Alternatively, a\n> .git/objects/??/*.metadata per object could make sense.\n\nOne other possibility which occurs: would it be possible to store\npermissions, attributes and so on in a header line (or header lines) in the\nblob itself, which are stripped from the file and applied to the filesystem\nby a smudge filter, and added back by a clean filter?\n\nIf it works sensibly, this is roughly equivalent to adding a .gitmetadata\nfile as you suggest above, except that the permissions and attribute data\nare stored with each file, so the resulting diffs will be nicer and merges\nshould always be trivial without any special handling.\n\n(Disclaimer: I've never tried using smudge filters; maybe they can't be used\nin the way I describe!)\n\nCheers,\n\nChris.\n"},{"id":"165482","messageId":"BANLkTim5DPjGjJ=SfnNfXpzCd6=PKnSs6g@mail.gmail.com","threadId":"27028","inReplyTo":"20110409081108.GE13750@arachsys.com","subject":"Re: Tracking file metadata in git -- fix metastore or enhance git?","fromName":"Richard Hartmann","fromEmail":"richih.mailinglist@gmail.com","sentAt":"2011-04-09T09:09:22Z","receivedAt":"2011-04-09T09:09:22Z","isPatch":false,"sender":{"key":"richih.mailinglist@gmail.com","avatar":"https://avatars.githubusercontent.com/u/754723?v=4"},"body":"On Sat, Apr 9, 2011 at 10:11, Chris Webb wrote:\n\n> (Disclaimer: I've never tried using smudge filters; maybe they can't be used\n> in the way I describe!)\n\nSmudge filters are on my half-read list of New Cool Stuff so I can't\nreally comment on this.\n\nAnother idea would be to simply tack all metadata into the same place\nas the existing chmod stuff.\n\nWhile one large text file would be nice in case one wanted to make\nmanual changes, attaching versioned, binary information to every\nobject directly is a lot more efficient. I think I am convinced the\nlatter would be the cleaner approach, now. With a clean layout, this\nwould not need to be a huge code drop supporting every metadata type\nin existence; it could be extended as needed.\n\nAs noted above, .gitattributes could be used to manage what kind of\nmetadata should be stored.\n\n\nOne large question in my mind is if anyone who's familiar enough with\nthe codebase and has the time would be interested in actually\nimplementing this.\n\n\nThanks,\nRichard\n"},{"id":"165519","messageId":"20110410001518.GA6380@elie","threadId":"27028","inReplyTo":"BANLkTim5DPjGjJ=SfnNfXpzCd6=PKnSs6g@mail.gmail.com","subject":"Re: Tracking file metadata in git -- fix metastore or enhance git?","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-04-10T00:15:18Z","receivedAt":"2011-04-10T00:15:18Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi again.\n\nChris Webb wrote:\n\n> (Disclaimer: I've never tried using smudge filters; maybe they can't be used\n> in the way I describe!)\n\nIn the current form, they couldn't. smudge/clean filters take their\ninput through stdin and write their output to stdout --- there is not\na chance to look at the on-disk directory entry to get metadata.\n\nIt might be possible to introduce a new %p substitution pointing to\nthe actual file the filter is working on, since with a few exceptions,\nthe file passed to a clean filter is already on-disk. Exceptions:\n\n * \"git blame --contents=- -- \" reads from stdin instead of .\n\n * the low-level --renormalize facility (see git-merge(1)) and its\n callers feed a clean filter with output from a smudge filter before\n content hits the disk.\n\n * \"git hash-object --path= --stdin\" reads from stdin instead of\n .\n\nI'd be worried about using a clean filter to store timestamps.\nTreating a file as changed whenever mtime changes could be confusing.\nTreating atime changes as content changes would be even stranger.\n\nRichard Hartmann wrote:\n\n> One large question in my mind is if anyone who's familiar enough with\n> the codebase and has the time would be interested in actually\n> implementing this.\n\nI don't think this has to touch git core, except perhaps as mentioned\nabove. Please feel free to cc me if working on hooks (pre-commit hook\nor clean filter) to automatically track metadata and some mechanism to\nrestore it. I'd be glad to give feedback and help in any other way I\ncan.\n\nTo be clear, I will not be driving this forward --- it's just not\nsomething I've ever needed, so I'd trust others to do a better job of\ntaking good care of the actual use cases.\n\nCiao,\nJonathan\n"},{"id":"165522","messageId":"7v39lqzzn9.fsf@alter.siamese.dyndns.org","threadId":"27028","inReplyTo":"20110410001518.GA6380@elie","subject":"Re: Tracking file metadata in git -- fix metastore or enhance git?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-04-10T01:03:06Z","receivedAt":"2011-04-10T01:03:06Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder writes:\n\n> I'd be worried about using a clean filter to store timestamps.\n> Treating a file as changed whenever mtime changes could be confusing.\n> Treating atime changes as content changes would be even stranger.\n\nThat is exactly why git does not store metainfo. Storing auxiliary\ninformation on commit objects or tree objects to help build or deploy\nprocedures is fine, but that kind of information should be stored\nsomewhere that the normal git operations would not care about.\n"},{"id":"165524","messageId":"BANLkTimbAmW+ueq1Z9PJN9opXggywdxdnA@mail.gmail.com","threadId":"27028","inReplyTo":"7v39lqzzn9.fsf@alter.siamese.dyndns.org","subject":"Re: Tracking file metadata in git -- fix metastore or enhance git?","fromName":"Richard Hartmann","fromEmail":"richih.mailinglist@gmail.com","sentAt":"2011-04-10T01:31:13Z","receivedAt":"2011-04-10T01:31:13Z","isPatch":false,"sender":{"key":"richih.mailinglist@gmail.com","avatar":"https://avatars.githubusercontent.com/u/754723?v=4"},"body":"On Sun, Apr 10, 2011 at 03:03, Junio C Hamano wrote:\n\n> That is exactly why git does not store metainfo.  Storing auxiliary\n> information on commit objects or tree objects to help build or deploy\n> procedures is fine, but that kind of information should be stored\n> somewhere that the normal git operations would not care about.\n\nKeeping this information out of git's way during operations in which\nit's not needed is obviously A Good Thing. Yet, this would only happen\nwhen this information has been added to the repository on purpose.\nThus, I don't see this as a deal-breaker.\n\n\nRichard\n"},{"id":"165592","messageId":"BANLkTik=+Ne8x4GvOBJcy2_7AUYBS9n3oA@mail.gmail.com","threadId":"27028","inReplyTo":"BANLkTimbAmW+ueq1Z9PJN9opXggywdxdnA@mail.gmail.com","subject":"Re: Tracking file metadata in git -- fix metastore or enhance git?","fromName":"Richard Hartmann","fromEmail":"richih.mailinglist@gmail.com","sentAt":"2011-04-11T00:12:16Z","receivedAt":"2011-04-11T00:12:16Z","isPatch":false,"sender":{"key":"richih.mailinglist@gmail.com","avatar":"https://avatars.githubusercontent.com/u/754723?v=4"},"body":"FYI, Harley J Pig had this to say on the\nvcs-home mailing list\n\n> I've written a metastore clone for a project where we need to store a\n> linux distribution in version control (legacy code). I'm also using\n> it for my personal vcs-home stuff. It is a naive and bluntly\n> straightforward way to do this, but it seems to be working. You can\n> find it at https://github.com/harleypig/gitperms\n>\n> I use git hooks and a central file to (re)store the metadata. Maybe\n> it can be of some use to someone else.\n\n\nRichard\n"},{"id":"166021","messageId":"BANLkTimTszUC+4d3tMTP-cxG3AoWmr08HA@mail.gmail.com","threadId":"27028","inReplyTo":"BANLkTikkb3DUOtP9NUtNMNV5Z+oJ7AFHfg@mail.gmail.com","subject":"Re: Tracking file metadata in git -- fix metastore or enhance git?","fromName":"Richard Hartmann","fromEmail":"richih.mailinglist@gmail.com","sentAt":"2011-04-18T00:21:32Z","receivedAt":"2011-04-18T00:21:32Z","isPatch":false,"sender":{"key":"richih.mailinglist@gmail.com","avatar":"https://avatars.githubusercontent.com/u/754723?v=4"},"body":"Hi all,\n\nas I don't want to let this go stale, here are the three options:\n\n1) fix metastore\n2) default to gitperms\n3) extend git\n\n\nI still think 3) would be best, but someone would need to step up to\ndo this. Is anyone up for this task? If not, we will have to resort to\n1) or 2)\n\n\nThanks again,\nRichard\n"},{"id":"166022","messageId":"20110418004550.GA2529@elie","threadId":"27028","inReplyTo":"BANLkTimTszUC+4d3tMTP-cxG3AoWmr08HA@mail.gmail.com","subject":"Re: Tracking file metadata in git -- fix metastore or enhance git?","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-04-18T00:45:51Z","receivedAt":"2011-04-18T00:45:51Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi again,\n\nNot sure if my thoughts will be useful here since you dropped me from\nthe cc list. But anyway:\n\nRichard Hartmann wrote:\n\n> here are the three options:\n>\n> 1) fix metastore\n> 2) default to gitperms\n> 3) extend git\n>\n> I still think 3) would be best, but someone would need to step up to\n> do this. Is anyone up for this task? If not, we will have to resort to\n> 1) or 2)\n\nThe usual practice in git development is\n\n (1) people make scripts wrapping plumbing commands (see git(1)) that\n work well for themselves\n (2) they tell the git list about it and publish it\n (3) an idea emerges that this is suitable for inclusion, and it\n gets included\n\nIn particular, git's design is not so monolithic --- \"extend git\" can\nmean \"add a script\" or \"add a builtin\" so it is not so involved as you\nseem to think. See also contrib/README for a place to stop on the\nway.\n\nAnyway, if you want something the just works, my suggestion is (4) use\nthe hook scripts from etckeeper. Last time I looked into this they\nworked better than metastore.\n\nHope that helps.\nJonathan\n"},{"id":"181111","messageId":"1323838492627-7092383.post@n2.nabble.com","threadId":"27028","inReplyTo":"20110418004550.GA2529@elie","subject":"Re: Tracking file metadata in git -- fix metastore or enhance git?","fromName":"johnnyutahh","fromEmail":"git.nabble.com@johnnyutahh.com","sentAt":"2011-12-14T04:54:52Z","receivedAt":"2011-12-14T04:54:52Z","isPatch":false,"sender":{"key":"git.nabble.com@johnnyutahh.com","avatar":null},"body":"Following up on \nhttp://git.661346.n2.nabble.com/Tracking-file-metadata-in-git-fix-metastore-or-enhance-git-td6251248.html\nthis discussion re: git file-metadata-management , posted this:\n\nhttp://superuser.com/questions/367729/how-to-reuse-extend-etckeepers-metadata-engine-for-git-control-of-non-etc-file\n\nAny further movement on this topic?\n\n\n\nJonathan Nieder-2 wrote\n> \n> Hi again,\n> \n> Not sure if my thoughts will be useful here since you dropped me from\n> the cc list. But anyway:\n> \n> Richard Hartmann wrote:\n> \n>> here are the three options:\n>>\n>> 1) fix metastore\n>> 2) default to gitperms\n>> 3) extend git\n>>\n>> I still think 3) would be best, but someone would need to step up to\n>> do this. Is anyone up for this task? If not, we will have to resort to\n>> 1) or 2)\n> \n> The usual practice in git development is\n> \n> (1) people make scripts wrapping plumbing commands (see git(1)) that\n> work well for themselves\n> (2) they tell the git list about it and publish it\n> (3) an idea emerges that this is suitable for inclusion, and it\n> gets included\n> \n> In particular, git's design is not so monolithic --- \"extend git\" can\n> mean \"add a script\" or \"add a builtin\" so it is not so involved as you\n> seem to think. See also contrib/README for a place to stop on the\n> way.\n> \n> Anyway, if you want something the just works, my suggestion is (4) use\n> the hook scripts from etckeeper. Last time I looked into this they\n> worked better than metastore.\n> \n> Hope that helps.\n> Jonathan\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@.kernel\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n> \n\n\n--\nView this message in context: http://git.661346.n2.nabble.com/Tracking-file-metadata-in-git-fix-metastore-or-enhance-git-tp6251248p7092383.html\nSent from the git mailing list archive at Nabble.com.\n"},{"id":"181503","messageId":"CAD77+gS0qUbsCA-Aba9rAyAf-EGZ5jDtsBuwmp7aM+0tf+rQcQ@mail.gmail.com","threadId":"27028","inReplyTo":"1323838492627-7092383.post@n2.nabble.com","subject":"Re: Tracking file metadata in git -- fix metastore or enhance git?","fromName":"Richard Hartmann","fromEmail":"richih.mailinglist@gmail.com","sentAt":"2011-12-20T00:55:55Z","receivedAt":"2011-12-20T00:55:55Z","isPatch":false,"sender":{"key":"richih.mailinglist@gmail.com","avatar":"https://avatars.githubusercontent.com/u/754723?v=4"},"body":"On Wed, Dec 14, 2011 at 05:54, johnnyutahh\n wrote:\n\n> Any further movement on this topic?\n\nNot really. ATM, our best bet is to agree on a language and just implement it.\n\n\nRichard\n"}]}