{"thread":{"id":"16512","subject":"timestamps not git-cloned","startedAt":"2008-11-28T02:24:04Z","lastAt":"2008-12-01T11:44:37Z","messageCount":16,"participants":["jidanni@jidanni.org","dhruva","David Brown","Daniel Barkalow","Johannes Schindelin","Robin Rosenberg","Peter Krefting","Chris Frey","Stephen R. van den Berg","Thomas Rast","Sitaram Chamarty","Andreas Ericsson","Jakub Narebski"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"96669","messageId":"87ej0wwptn.fsf@jidanni.org","threadId":"16512","inReplyTo":null,"subject":"timestamps not git-cloned","fromName":"","fromEmail":"jidanni@jidanni.org","sentAt":"2008-11-28T02:24:04Z","receivedAt":"2008-11-28T02:24:04Z","isPatch":false,"sender":{"key":"jidanni@jidanni.org","avatar":"https://gravatar.com/avatar/36568d4af4c8d3e71627ef3b8c8d00e39065b12f29676cccd38ced75e68fa2a6?d=mp&s=160"},"body":"Gentlemen, it's my first git-clone,\n$ git-clone git://git.debian.org/git/pkg-fso/files.git\nand I'm disappointed to find the timestamps of the files created are\nall now and not the date of last edit. At least mention something\nabout this on the git-clone man page.\n"},{"id":"96670","messageId":"e3f230850811271908g1be6b3f9t3e678081088de06b@mail.gmail.com","threadId":"16512","inReplyTo":"87ej0wwptn.fsf@jidanni.org","subject":"Re: timestamps not git-cloned","fromName":"dhruva","fromEmail":"dhruvakm@gmail.com","sentAt":"2008-11-28T03:08:06Z","receivedAt":"2008-11-28T03:08:06Z","isPatch":false,"sender":{"key":"dhruvakm@gmail.com","avatar":"https://gravatar.com/avatar/96fe022a95b60fd0de7f9f521364d964cdc7c46be5cfef279f8d4379e49e19a6?d=mp&s=160"},"body":"Hi,\n\nOn Fri, Nov 28, 2008 at 7:54 AM,  <jidanni@jidanni.org> wrote:\n> Gentlemen, it's my first git-clone,\n> $ git-clone git://git.debian.org/git/pkg-fso/files.git\n> and I'm disappointed to find the timestamps of the files created are\n> all now and not the date of last edit. At least mention something\n> about this on the git-clone man page.\n\nI do not think there is an VCS that records timestamps. Only file\ncontents are tracked. Also, if you clone from systems across time\nzones, what time do you expect to set on the files. IMO, it is not\npractical to track timestamps.\n Are you concerned of 'make' doing a complete build when you switch\nbranches? I guess it makes sense only in that scenario. I wish 'make'\nhad some feature to track changes instead of timestamps alone...\n\n-dhruva\n\n-- \nContents reflect my personal views only!\n"},{"id":"96672","messageId":"87tz9sv3rb.fsf@jidanni.org","threadId":"16512","inReplyTo":"e3f230850811271908g1be6b3f9t3e678081088de06b@mail.gmail.com","subject":"Re: timestamps not git-cloned","fromName":"","fromEmail":"jidanni@jidanni.org","sentAt":"2008-11-28T05:06:00Z","receivedAt":"2008-11-28T05:06:00Z","isPatch":false,"sender":{"key":"jidanni@jidanni.org","avatar":"https://gravatar.com/avatar/36568d4af4c8d3e71627ef3b8c8d00e39065b12f29676cccd38ced75e68fa2a6?d=mp&s=160"},"body":">>>>> \"d\" == dhruva  <dhruvakm@gmail.com> writes:\n\nd> Also, if you clone from systems across time zones, what time do you\nd> expect to set on the files.\n\nI'm just used to tar, cpio, scp -a, rsync -a, ar, etc. using 'date +%s'\nseconds internally, so no timezone problem.\n\nI hate it when I get some latest WhizBang.tgz, only to untar it to\nfind all the files' dates the same, when in fact the README hasn't\nbeen touched in seven years, but you can't tell that from ls -l. I\nrecall some content tracker was involved.\n\nOf course I'll allowing you to know my delicate first day impressions.\nI'm sure as I grow older I will learn the difference between content\ntracker and archiver.\n"},{"id":"96673","messageId":"20081128055758.GA17123@linode.davidb.org","threadId":"16512","inReplyTo":"e3f230850811271908g1be6b3f9t3e678081088de06b@mail.gmail.com","subject":"Re: timestamps not git-cloned","fromName":"David Brown","fromEmail":"git@davidb.org","sentAt":"2008-11-28T05:57:58Z","receivedAt":"2008-11-28T05:57:58Z","isPatch":false,"sender":{"key":"git@davidb.org","avatar":"https://gravatar.com/avatar/94c86a2938470a74c2eac5e2b69afc0871f79a660295c02219597aba8cb101c1?d=mp&s=160"},"body":"On Fri, Nov 28, 2008 at 08:38:06AM +0530, dhruva wrote:\n\n>I do not think there is an VCS that records timestamps.\n\nPerforce does, at least optionally.  But, it's model is so different,\nI'm not sure it really applies here.  I believe it can either be an\nindividual file setting, or for a whole workspace.\n\nDavid\n"},{"id":"96676","messageId":"alpine.LNX.1.00.0811280058230.19665@iabervon.org","threadId":"16512","inReplyTo":"87tz9sv3rb.fsf@jidanni.org","subject":"Re: timestamps not git-cloned","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2008-11-28T06:59:45Z","receivedAt":"2008-11-28T06:59:45Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Fri, 28 Nov 2008, jidanni@jidanni.org wrote:\n\n> >>>>> \"d\" == dhruva  <dhruvakm@gmail.com> writes:\n> \n> d> Also, if you clone from systems across time zones, what time do you\n> d> expect to set on the files.\n> \n> I'm just used to tar, cpio, scp -a, rsync -a, ar, etc. using 'date +%s'\n> seconds internally, so no timezone problem.\n> \n> I hate it when I get some latest WhizBang.tgz, only to untar it to\n> find all the files' dates the same, when in fact the README hasn't\n> been touched in seven years, but you can't tell that from ls -l. I\n> recall some content tracker was involved.\n\nWell, README was just touched; it wasn't on your disk at all shortly \nbefore. This would make a big difference if, for example, you unpacked \n\"foo-1.0\" on top of \"foo-1.1\" and the timestamps were from when the files \nwere originally created, and now all of the source files that changed are \nolder than the object files and the build system does nothing.\n\nOf course, with archives, you don't unpack different versions into the \nsame directory, but with a version control system, you'll do it all the \ntime, so you really need the system to put on disk the times when those \nfiles were last put there. If you want to know when the README you've got \nis from (and a whole lot more) \"git log README\" will tell you, although it \nwon't tell you if somebody yesterday changed the README they're \ndistributing from some other text to a file that's been sitting on their \ndisk untouched for seven years.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"96682","messageId":"alpine.DEB.1.00.0811281248230.30769@pacific.mpi-cbg.de","threadId":"16512","inReplyTo":"87ej0wwptn.fsf@jidanni.org","subject":"Re: timestamps not git-cloned","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-11-28T11:51:08Z","receivedAt":"2008-11-28T11:51:08Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 28 Nov 2008, jidanni@jidanni.org wrote:\n\n> Gentlemen, it's my first git-clone,\n> $ git-clone git://git.debian.org/git/pkg-fso/files.git\n> and I'm disappointed to find the timestamps of the files created are\n> all now and not the date of last edit.\n\nYou are mistaken to be disappointed.  Granted, to a hammer, everything \nlooks like a nail.  But it might make more sense to be gentle, and insert \nthe syringe by hand.  Maybe it will get less painful that way, too.\n\nIn other words, do not be surprised when a source code management tool \nturns out to be lousy at recreating meta-data -- which has as much to do \nwith source code than a syringe with a nail.\n\nHth,\nDscho\n"},{"id":"96683","messageId":"200811281358.24592.robin.rosenberg.lists@dewire.com","threadId":"16512","inReplyTo":"87ej0wwptn.fsf@jidanni.org","subject":"Re: timestamps not git-cloned","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2008-11-28T12:58:24Z","receivedAt":"2008-11-28T12:58:24Z","isPatch":false,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"fredag 28 november 2008 03:24:04 skrev jidanni@jidanni.org:\n> Gentlemen, it's my first git-clone,\n> $ git-clone git://git.debian.org/git/pkg-fso/files.git\n> and I'm disappointed to find the timestamps of the files created are\n> all now and not the date of last edit. At least mention something\n> about this on the git-clone man page.\n\nI recommend every new Git user to scan the FAQ. It's not just clone,\nit's in everything git does in the file system. There is a very good \nreason git behaves this way in general, although clone could be\nexception, but then we would have a ton of questions about that\ninconsistency.\n\n-- robin\n"},{"id":"96684","messageId":"alpine.DEB.1.00.0811281418530.30769@pacific.mpi-cbg.de","threadId":"16512","inReplyTo":"200811281358.24592.robin.rosenberg.lists@dewire.com","subject":"Re: timestamps not git-cloned","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-11-28T13:20:55Z","receivedAt":"2008-11-28T13:20:55Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 28 Nov 2008, Robin Rosenberg wrote:\n\n> I recommend every new Git user to scan the FAQ. It's not just clone,\n> it's in everything git does in the file system. There is a very good \n> reason git behaves this way in general, although clone could be\n> exception, but then we would have a ton of questions about that\n> inconsistency.\n\nNo, clone cannot be an exception.  The information is just not stored, and \nfor a good reason: a file's timestamp is nothing you want to commit in \nsource code management.  It just does not make sense at all.\n\nCiao,\nDscho\n"},{"id":"96687","messageId":"Pine.LNX.4.64.0811281554560.14606@ds9.cixit.se","threadId":"16512","inReplyTo":"e3f230850811271908g1be6b3f9t3e678081088de06b@mail.gmail.com","subject":"Re: timestamps not git-cloned","fromName":"Peter Krefting","fromEmail":"peter@softwolves.pp.se","sentAt":"2008-11-28T14:59:56Z","receivedAt":"2008-11-28T14:59:56Z","isPatch":false,"sender":{"key":"peter@softwolves.pp.se","avatar":"https://avatars.githubusercontent.com/u/990764?v=4"},"body":"Hi!\n\ndhruva:\n\n> I do not think there is an VCS that records timestamps. Only file\n> contents are tracked.\n\nCVS sort of does. The initial checkout sets the time stamp of files to\ntheir last *check-in* time (and you can import a file with -D to set\nits commit time to the current timestamp). Updates do, however, set to\ncurrent time (to not break make and friends).\n\nI miss this behaviour in Git, but I have learnt to live with it. I\nguess it is like a difference in philosophy on what time-stamps are\nsupposed to record, like how UNIX \"cp\" sets the time of the new-born\ncopy to now, while DOS \"copy\" sets it to the old time-stamp. Coming\nto Unix and Linux from DOS (via OS/2), I find \"cp\" behaviour weird. But\nhave learnt to live with it (and use \"cp -a\" a lot).\n\n-- \n\\\\// Peter - http://www.softwolves.pp.se/\n"},{"id":"96710","messageId":"20081129085406.GA20428@foursquare.net","threadId":"16512","inReplyTo":"87tz9sv3rb.fsf@jidanni.org","subject":"Re: timestamps not git-cloned","fromName":"Chris Frey","fromEmail":"cdfrey@foursquare.net","sentAt":"2008-11-29T08:54:06Z","receivedAt":"2008-11-29T08:54:06Z","isPatch":false,"sender":{"key":"cdfrey@foursquare.net","avatar":null},"body":"On Fri, Nov 28, 2008 at 01:06:00PM +0800, jidanni@jidanni.org wrote:\n> I hate it when I get some latest WhizBang.tgz, only to untar it to\n> find all the files' dates the same, when in fact the README hasn't\n> been touched in seven years, but you can't tell that from ls -l. I\n> recall some content tracker was involved.\n\nIf this is the important bit, perhaps git-archive could be changed\nto create tarballs with file timestamps based on their commit dates.\n\n- Chris\n"},{"id":"96711","messageId":"20081129092231.GA32630@cuci.nl","threadId":"16512","inReplyTo":"20081129085406.GA20428@foursquare.net","subject":"Re: timestamps not git-cloned","fromName":"Stephen R. van den Berg","fromEmail":"srb@cuci.nl","sentAt":"2008-11-29T09:22:31Z","receivedAt":"2008-11-29T09:22:31Z","isPatch":false,"sender":{"key":"srb@cuci.nl","avatar":"https://gravatar.com/avatar/f75389059e827634d38e9df2a9b6ecbd50028b5a454442efa1c7205b7ff29c6a?d=mp&s=160"},"body":"Chris Frey wrote:\n>On Fri, Nov 28, 2008 at 01:06:00PM +0800, jidanni@jidanni.org wrote:\n>> I hate it when I get some latest WhizBang.tgz, only to untar it to\n>> find all the files' dates the same, when in fact the README hasn't\n>> been touched in seven years, but you can't tell that from ls -l. I\n>> recall some content tracker was involved.\n\n>If this is the important bit, perhaps git-archive could be changed\n>to create tarballs with file timestamps based on their commit dates.\n\nBased on the principle of least surprise, I'd consider this a rather good\nidea.\n-- \nSincerely,\n           Stephen R. van den Berg.\n\nTo people that say \"I could care less\" - well, why don't you?\n"},{"id":"96712","messageId":"200811291117.01655.trast@student.ethz.ch","threadId":"16512","inReplyTo":"20081129092231.GA32630@cuci.nl","subject":"Re: timestamps not git-cloned","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2008-11-29T10:16:58Z","receivedAt":"2008-11-29T10:16:58Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Stephen R. van den Berg wrote:\n> Chris Frey wrote:\n> >If this is the important bit, perhaps git-archive could be changed\n> >to create tarballs with file timestamps based on their commit dates.\n> \n> Based on the principle of least surprise, I'd consider this a rather good\n> idea.\n\nUnless I'm missing something, this would make git-archive rather more\nexpensive than it is now: Tree objects do not record any timestamps,\nso figuring out the last commit that changed a file requires a full\nhistory walk in the worst case[*].  (This is another side-effect of\nnot versioning files.)  On the other hand, current git-archive's\nrunning time depends only on the size of the tree-ish given, including\nall subtrees and blobs.\n\nMy unscientific guesstimates on how much work this would be, in a\nrandom (old) linux-2.6 clone:\n\n  $ git rev-parse HEAD\n  e013e13bf605b9e6b702adffbe2853cfc60e7806\n  $ time git ls-tree -r -t $(git rev-list HEAD~5000..HEAD) >/dev/null\n\n  real    0m1.385s\n  user    0m1.164s\n  sys     0m0.220s\n  $ git rev-list HEAD | wc -l\n  117812\n\nSo reading (and dumping) all those trees and subtrees incurs a penalty\non the order of 30 seconds.  Compare to the current running time of\ngit-archive:\n\n  $ time git archive --format=tar HEAD >/dev/null\n\n  real    0m2.790s\n  user    0m2.684s\n  sys     0m0.072s\n\nOf course, the ratio will keep getting worse as history gets longer.\n\n- Thomas\n\n[*] I think to really have a \"worst case\" here, you need at least one\nfile in every leaf directory that has not changed since the root\ncommit, and another that changes in every commit to force the search\nto really read every subtree.\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n\n\n\n"},{"id":"96751","messageId":"87k5am3uom.fsf@jidanni.org","threadId":"16512","inReplyTo":"200811291117.01655.trast@student.ethz.ch","subject":"Re: timestamps not git-cloned","fromName":"","fromEmail":"jidanni@jidanni.org","sentAt":"2008-11-30T00:48:41Z","receivedAt":"2008-11-30T00:48:41Z","isPatch":false,"sender":{"key":"jidanni@jidanni.org","avatar":"https://gravatar.com/avatar/36568d4af4c8d3e71627ef3b8c8d00e39065b12f29676cccd38ced75e68fa2a6?d=mp&s=160"},"body":"Well all I know is from the simple user who does e.g.,\n# aptitude install linux-doc-2.6.26\n# ls -lt /usr/share/doc/linux-doc-2.6.26/Documentation/\nhe thinks \"gosh, can't tell what's new vs. what hasn't changed in years\".\n\nOK, now I know why this is tolerable upstream: they all use git.\n\nBut for the lowly user downstream who gets what git-archive produces,\nit seems like a step backwards: \"who threw away the timestamp of when\neach file was last changed?\".\n\nOK, http://git.or.cz/gitwiki/ContentLimitations says this is by design.\n\nAnd OK, thinking \"file by file\" is old fashioned, I read. The non-git\nend user should just get used to reading ChangeLogs, if any, and stop\ndoing ls -lt.\n\nBut you must admit, /usr/share/doc/linux-doc-2.6.26/Documentation/\netc. are aimed for reading without git.\n\nAnyways, if just in case any individual file modification time\ninformation can still be pried from the 40 byte IDs or whatever, I\nwould suggest using it by default in git-archive at least, and maybe\neven git-clone etc.\n\nJust letting you know my 'valuable first impressions'. I expect once I\nstart smoking more of this \"git\" stuff, I too will become comfortably\nnumb to aforementioned lowly user problem, so you would never know\nunless I hereby first told you before it was too late.\n"},{"id":"96753","messageId":"2e24e5b90811291714s4388289bwa4b2e22ff1f75a83@mail.gmail.com","threadId":"16512","inReplyTo":"200811291117.01655.trast@student.ethz.ch","subject":"Re: timestamps not git-cloned","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2008-11-30T01:14:38Z","receivedAt":"2008-11-30T01:14:38Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"On Sat, Nov 29, 2008 at 3:46 PM, Thomas Rast <trast@student.ethz.ch> wrote:\n> Stephen R. van den Berg wrote:\n>> Chris Frey wrote:\n>> >If this is the important bit, perhaps git-archive could be changed\n>> >to create tarballs with file timestamps based on their commit dates.\n>>\n>> Based on the principle of least surprise, I'd consider this a rather good\n>> idea.\n>\n> Unless I'm missing something, this would make git-archive rather more\n> expensive than it is now: Tree objects do not record any timestamps,\n\nHow many people use git-archive and how many times a day do they use\nit?  For example, kernel.org seems to put out linux-2.x.y.z.tar.bz2\nonce every 2 to 7 days.\n\nThe overhead of this new option (and certainly it should be an option,\nnot the default) should be measured not against the old running time,\nbut against the frequency of usage of the tool.  Look at it on those\ntime scales, it may not be a big deal.\n\nBy all accounts, this overhead will not affect the \"giterate\" [meaning\ngit-literate ;-)] people too much.\n"},{"id":"96815","messageId":"4933A9B1.3070904@op5.se","threadId":"16512","inReplyTo":"87k5am3uom.fsf@jidanni.org","subject":"Re: timestamps not git-cloned","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2008-12-01T09:09:05Z","receivedAt":"2008-12-01T09:09:05Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"jidanni@jidanni.org wrote:\n> Well all I know is from the simple user who does e.g.,\n> # aptitude install linux-doc-2.6.26\n> # ls -lt /usr/share/doc/linux-doc-2.6.26/Documentation/\n> he thinks \"gosh, can't tell what's new vs. what hasn't changed in years\".\n> \n\nThey won't be able to do that anyway, since a spelling correction\nwould update the timestamp anyway. The only way of finding out if\nthere are *content* changes (which is really what matters) is to\nuse some sort of history-browser for those documents. Git is good\nfor that. The sort of people who really need to know when the docs\nchange can be exptected to have a higher technical knowledge than\nthe end-users, so it's not too much to ask that they use such a\nhistory browsing tool to find out what's new (or simply \"diff\").\n\nEither way, timestamps on documents are a very poor way of finding\nout when something really changed.\n\n> OK, now I know why this is tolerable upstream: they all use git.\n> \n> But for the lowly user downstream who gets what git-archive produces,\n> it seems like a step backwards: \"who threw away the timestamp of when\n> each file was last changed?\".\n> \n> OK, http://git.or.cz/gitwiki/ContentLimitations says this is by design.\n> \n> And OK, thinking \"file by file\" is old fashioned, I read. The non-git\n> end user should just get used to reading ChangeLogs, if any, and stop\n> doing ls -lt.\n> \n> But you must admit, /usr/share/doc/linux-doc-2.6.26/Documentation/\n> etc. are aimed for reading without git.\n> \n\nWell, /usr/bin/less doesn't require git to function, so I fail to see\nwhat the fuzz is all about.\n\n> Anyways, if just in case any individual file modification time\n> information can still be pried from the 40 byte IDs or whatever, I\n> would suggest using it by default in git-archive at least, and maybe\n> even git-clone etc.\n> \n\nIt can, but it's a fairly expensive operation, tracking each files\nSHA1 backwards in time to see when the commit was done that last made\nany changes to it. It's not something you want to do for an archive\ncontaining 26K files. Trust me on this.\n\n> Just letting you know my 'valuable first impressions'. I expect once I\n> start smoking more of this \"git\" stuff, I too will become comfortably\n> numb to aforementioned lowly user problem, so you would never know\n> unless I hereby first told you before it was too late.\n\n\nI see a lot of ranting but no patches from you. Since you're the one\nwith the itch, why not just submit a patch and see if distro packagers\nstart using it?\n\nSome words of advice though; Make it optional, or it'll be dropped on\nthe floor. For bonus points, make it calculate timestamps only for a\npath-spec delimited set of files. That'll cut down expected runtime\nby a *huge* amount for something like the linux kernel.\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n"},{"id":"96830","messageId":"m3tz9oi0im.fsf@localhost.localdomain","threadId":"16512","inReplyTo":"4933A9B1.3070904@op5.se","subject":"Re: timestamps not git-cloned","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-12-01T11:44:37Z","receivedAt":"2008-12-01T11:44:37Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Andreas Ericsson <ae@op5.se> writes:\n\n> I see a lot of ranting but no patches from you. Since you're the one\n> with the itch, why not just submit a patch and see if distro packagers\n> start using it?\n> \n> Some words of advice though; Make it optional, or it'll be dropped on\n> the floor. For bonus points, make it calculate timestamps only for a\n> path-spec delimited set of files. That'll cut down expected runtime\n> by a *huge* amount for something like the linux kernel.\n\nI think the old idea of 'tree blame' (search archives) would be a good\ninterface for this feature... if you decide to write it.\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"}]}