{"thread":{"id":"6989","subject":"Worrisome bug trend","startedAt":"2007-02-27T12:31:41Z","lastAt":"2007-03-03T02:28:27Z","messageCount":14,"participants":["Junio C Hamano","Randal L. Schwartz","Andy Parkins","Linus Torvalds","Johannes Schindelin","Sam Vilain","Alexandre Julliard","Robin Rosenberg","Dmitry V. Levin","Jakub Narebski"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"35598","messageId":"7vodnfg4sy.fsf@assigned-by-dhcp.cox.net","threadId":"6989","inReplyTo":null,"subject":"Worrisome bug trend","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-27T12:31:41Z","receivedAt":"2007-02-27T12:31:41Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"I was reviewing the bugs we fixed since v1.5.0 and noticed\nalmost all of them are ancient ones. We do have small number of\nbugs introduced by recently added commands and options, but I\nsee quite a few that are from 2005.\n\nI take that as a sign that git hasn't been exercised well and\nyet more ancient bugs are sleeping, waiting to be triggered, not\nas a sign that we are very careful and adding only small number\nof risky new code in the releases.\n\nWhich is kind of depressing...\n\nThe following table shows each bug fixed since v1.5.0, and the\ncommit that introduced the bug. Many bugs are attributed to the\nfirst commit that introduced the feature.\n\n20276889 (daemon socksetup() does not set FD_CLOEXEC)\n\ta87e8be2 Jul 13 2005\n\nde6f0def (no-trivial-merge)\n\t6ea23343 Mar 18 2006\n\nf4421325 (blame with missing parameter)\n\tcee7f245 Oct 19 2006\n\n185c975f (trust_executable_bit not trusting too much)\n\t3e09cdfd Oct 11 2005\n\n256c3fe6 (rev-list commit encoding)\n\t52883fbd Dec 25 2006\n\n75b62b48 (combine-diff broken cast)\n\te702496e Aug 23 2006 (memcpy->hashcpy)\n\tfunny thing is that another similar cast is correct.\n\n8ab40a20 (show-ref --verify)\n\t26cdd1e7 Dec 17 2006\n\nc06d2daa (format-patch filename length)\n\t0acfc972 Jul 5 2005\n\n50892777 (diff --git a//etc/inittab)\n\t65056021 Apr 28 2006 (first built-in diff)\n\nab242f80 rerere (find_conflict skips adjacent)\n\t658f3650 Dec 20 2006 (inception, C rewrite)\n\n12891727 rerere (find_conflict uses symlinks)\n\t658f3650 Dec 20 2006 (inception, C rewrite)\n\t8389b52b Jan 28 2006 (original Perl version)\n\nffa84ffb (pack-object fixed arglen)\n\t8d1d8f83 Sep 06 2006 \n\n308efc10 (merge-index symlink handling)\n\t54dd99a1 Dec 02 2005\n\n17cd29b2 (merge-recursive symlink handling)\n\t3af244ca Jul 27 2006\n\n4fc970c4 (diff --cc symlink while merging)\n\tea726d02 Jan 28 2006 (teach --cc to diff-files)\n\n4e5104c1 (git-remote command did not like dots in name)\n\te194cd1e Jan 03 2007\n\n34fc5cef (mailinfo choke with too long a line)\n\tc5f7674a Jul 16 2005 (inception)\n\nee24ee55 (diff --cc int vs size_t)\n\t4fc970c4 Feb 25 2007\n\n63e50d49 (apply fixes whitespace errors of context lines)\n\td0c25035 Sep 23 2006 (inception of feature)\n"},{"id":"35621","messageId":"86odnfr625.fsf@blue.stonehenge.com","threadId":"6989","inReplyTo":"7vodnfg4sy.fsf@assigned-by-dhcp.cox.net","subject":"Re: Worrisome bug trend","fromName":"Randal L. Schwartz","fromEmail":"merlyn@stonehenge.com","sentAt":"2007-02-27T15:09:06Z","receivedAt":"2007-02-27T15:09:06Z","isPatch":false,"sender":{"key":"merlyn@stonehenge.com","avatar":"https://gravatar.com/avatar/dc528d210743ff0333e6213f9ee7b33b23f1b7bc1f3c5a8c2d819074ecd7ab19?d=mp&s=160"},"body":">>>>> \"Junio\" == Junio C Hamano writes:\n\nJunio> Which is kind of depressing...\n\nMaybe if you looked at who has been reporting the bugs, you'd find a different\nstory. It's quite possible that the \"inner circle\" all used git in a\nhomogeneous way, not performing every possible advertised operation, but now\nthat git is being used by more people, older bugs are getting revealed because\npeople really are using it out there in some nicely unique (or perhaps\nboneheaded :) ways.\n\nAny quick stats on diversity of bug submitters?\n\n-- \nRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095\n \nPerl/Unix/security consulting, Technical writing, Comedy, etc. etc.\nSee PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!\n"},{"id":"35628","messageId":"200702271536.39864.andyparkins@gmail.com","threadId":"6989","inReplyTo":"7vodnfg4sy.fsf@assigned-by-dhcp.cox.net","subject":"Re: Worrisome bug trend","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-02-27T15:36:38Z","receivedAt":"2007-02-27T15:36:38Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Tuesday 2007 February 27 12:31, Junio C Hamano wrote:\n\n> Which is kind of depressing...\n\nMaybe not. It's my feeling that the traffic on the git list has taken a \nsignificant jump lately. There have been a lot of new users asking \nquestions.\n\nCould it be that more users equals more bug reports? Could it also be that \nnew users tend to use git (let's put this politely) \"outside of the box\".\n\nThe users popping up on the list will be a small percentage of actually \nusing/adopting git. I think it's great, not depressing. I'm a relatively \nnew user of git, and just in the time I've been lurking the bugs/issues that \naffect me have dropped significantly.\n\nAs the philosopher says: don't worry, be happy. :-)\n\n\n\nAndy\n\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"35634","messageId":"Pine.LNX.4.64.0702270751260.12485@woody.linux-foundation.org","threadId":"6989","inReplyTo":"7vodnfg4sy.fsf@assigned-by-dhcp.cox.net","subject":"Re: Worrisome bug trend","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-02-27T16:00:36Z","receivedAt":"2007-02-27T16:00:36Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 27 Feb 2007, Junio C Hamano wrote:\n> \n> I take that as a sign that git hasn't been exercised well and\n> yet more ancient bugs are sleeping, waiting to be triggered, not\n> as a sign that we are very careful and adding only small number\n> of risky new code in the releases.\n\nI'd say that it's good news. I'd be a lot more worried if there is a big \nrash of *new* bugs being introduced, rather than small and subtle *old* \nbugs being fixed.\n\nThere were a number of \"December, 2006\" bugs there, and I'd worry more \nabout those. The old bugs were all fairly obscure (face it, nobody \nactually uses SCM's to track symlinks, because symlinks are not \nhistorically tracked by most SCM's).\n\nAnd the _really_ old bugs (eg the mailinfo one) were either features that \nyou'd never use on Unix anyway (trust_executable_bit) and thus haven't \ngotten any testing, or were about over-long buffers that mostly wouldn't \nrealistically trigger in practice (ie lack of coverage).\n\nFinding bugs is good. Some of it may well be due to just having more \nusers. And much of it is probably because everybody has bugs - but \nabsolutely none of the bugs on that list looked even remotely like a \"we'd \nscrew up the repository\". They were all pretty much harmless details.\n\n\t\tLinus\n"},{"id":"35658","messageId":"Pine.LNX.4.63.0702272057220.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6989","inReplyTo":"7vodnfg4sy.fsf@assigned-by-dhcp.cox.net","subject":"Re: Worrisome bug trend","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-02-27T20:00:54Z","receivedAt":"2007-02-27T20:00:54Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 27 Feb 2007, Junio C Hamano wrote:\n\n> I was reviewing the bugs we fixed since v1.5.0 and noticed almost all of \n> them are ancient ones. We do have small number of bugs introduced by \n> recently added commands and options, but I see quite a few that are from \n> 2005.\n\nI tend to agree with all the answers that this trend is to be expected.\n\nEspecially since we seem to attract more and more users who are unable or \nunwilling to fix the bugs themselves (up until recently, most bug reports \nseemed to me to be accompanied by patches).\n\nSo, it does not appear worrisome to me.\n\nHowever, I would like to see people thinking about how to teach \"sparse\" \nto catch those kind of errors so that we can actually learn in an \nefficient way from our mistakes.\n\nFor example, I refuse to believe that an error like checking int against \nssize_t cannot be found by \"sparse\".\n\nCiao,\nDscho\n"},{"id":"35665","messageId":"7vzm6zcpv0.fsf@assigned-by-dhcp.cox.net","threadId":"6989","inReplyTo":"86odnfr625.fsf@blue.stonehenge.com","subject":"Re: Worrisome bug trend","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-27T20:22:43Z","receivedAt":"2007-02-27T20:22:43Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"merlyn@stonehenge.com (Randal L. Schwartz) writes:\n\n>>>>>> \"Junio\" == Junio C Hamano writes:\n>\n> Junio> Which is kind of depressing...\n>\n> Maybe if you looked at who has been reporting the bugs, you'd\n> find a different story. It's quite possible that the \"inner\n> circle\" all used git in a homogeneous way, not performing\n> every possible advertised operation, but now that git is being\n> used by more people, older bugs are getting revealed because\n> people really are using it out there in some nicely unique (or\n> perhaps boneheaded :) ways.\n>\n> Any quick stats on diversity of bug submitters?\n\nI do not know how others noticed them but I am guessing most of\nthem were found out by hitting a breakage in real life use.\nAnnotated list of reporters and context of discovery is attached\nat the end.\n\nObservations.\n\n - There are a handful 'missing argument validation and erroring\n out' bugs. People in the know tend not make such a mistake\n to trigger these bugs, so it is a sign that git is being used\n by wider population that these bugs are surfacing now.\n\n - A few leaks and hardwired limits are signs that the code was\n not used for heavy-duty settings back when it was written,\n but it is now.\n\n - Tracking symlinks were added quite early by explicit need to\n support them in the kernel archive, and the bug was there\n ever since and nobody noticed. Maybe the need for tracking\n symlinks in SCM were real but they never got changed by more\n than one party (not needing merges).\n\n - There are a few \"diff --cc\" fixes. Maybe not as many people\n perform \"interesting\" merges as the effort spent on writing\n the --cc codde.\n\n - rerere's skipping adjacent paths were there from the\n beginning of C-rewrite. It's either rerere is not as widely\n used, or conflicting merges are not so frequent in real life\n to trigger this, or maybe a little bit of both.\n\n----------------------------------------------------------------\n\n20276889 (daemon socksetup() does not set FD_CLOEXEC)\n\ta87e8be2 Jul 13 2005\n\nAlex Julliard.\n\nf4421325 (blame with missing parameter)\n\tcee7f245 Oct 19 2006\n\nTommi Kyntola.\n\n256c3fe6 (rev-list commit encoding)\n\t52883fbd Dec 25 2006\n\nFredrik Kuivinen.\n\n8ab40a20 (show-ref --verify)\n\t26cdd1e7 Dec 17 2006\n\nDmitry V Levin.\n\nc06d2daa (format-patch filename length)\n\t0acfc972 Jul 5 2005\n\nRobin Rosenberg, presumaby by noticing breakage while dealing\nwith a foreign SCM import.\n\nffa84ffb (pack-object fixed arglen)\n\t8d1d8f83 Sep 06 2006 \n\nRoland Dreier, by noticing breakage.\n\n4e5104c1 (git-remote command did not like dots in name)\n\te194cd1e Jan 03 2007\n\nMany, by noticing breakage in real use.\n\n34fc5cef (mailinfo choke with too long a line)\n\tc5f7674a Jul 16 2005 (inception)\n\nLinus and Eric Biederman, by noticing breakage.\n\nee24ee55 (diff --cc int vs size_t)\n\t4fc970c4 Feb 25 2007\n\nJim Meyering, code inspection.\n\nde6f0def (no-trivial-merge)\n\t6ea23343 Mar 18 2006\n\nMe, while working on merge-subtree, by noticing breakage.\n\n185c975f (trust_executable_bit not trusting too much)\n\t3e09cdfd Oct 11 2005\n\nJohannes Sixt, presumably while working on MinGW port.\n\n75b62b48 (combine-diff broken cast)\n\te702496e Aug 23 2006 (memcpy->hashcpy)\n\tfunny thing is that another similar cast is correct.\n\nJohannes Schindelin.\n\n\n50892777 (diff --git a//etc/inittab)\n\t65056021 Apr 28 2006 (first built-in diff)\n\nMe, while looking at recent \"diff --no-index\" series, by noticing breakage.\n\nab242f80 rerere (find_conflict skips adjacent)\n\t658f3650 Dec 20 2006 (inception, C rewrite)\n\nMe, while diagnosing 12891727 below, by code inspection.\n\n12891727 rerere (find_conflict uses symlinks)\n\t658f3650 Dec 20 2006 (inception, C rewrite)\n\t8389b52b Jan 28 2006 (original Perl version)\n\nMe, while merging 'maint' into 'master', by noticing breakage.\n\n308efc10 (merge-index symlink handling)\n\t54dd99a1 Dec 02 2005\n\nMe, while merging 'maint' into 'master', by noticing breakage.\n\n17cd29b2 (merge-recursive symlink handling)\n\t3af244ca Jul 27 2006\n\nMe, while merging 'maint' into 'master', by noticing breakage.\n\n4fc970c4 (diff --cc symlink while merging)\n\tea726d02 Jan 28 2006 (teach --cc to diff-files)\n\nMe, while merging 'git-gui' into git.git, by noticing breakage.\n\n63e50d49 (apply fixes whitespace errors of context lines)\n\td0c25035 Sep 23 2006 (inception of feature)\n\nMe, while applying clean-up series from Nico last night, by noticing breakage.\n"},{"id":"35667","messageId":"45E493D3.7060407@vilain.net","threadId":"6989","inReplyTo":"7vodnfg4sy.fsf@assigned-by-dhcp.cox.net","subject":"Re: Worrisome bug trend","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2007-02-27T20:25:55Z","receivedAt":"2007-02-27T20:25:55Z","isPatch":false,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"Junio C Hamano wrote:\n> I take that as a sign that git hasn't been exercised well and\n> yet more ancient bugs are sleeping, waiting to be triggered, not\n> as a sign that we are very careful and adding only small number\n> of risky new code in the releases.\n> \n\nNo! It's a sign that there aren't enough tests :)\n\nMaybe investigate the coverage of the test suite?\n\nSam.\n"},{"id":"35668","messageId":"Pine.LNX.4.63.0702272129070.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6989","inReplyTo":"7vzm6zcpv0.fsf@assigned-by-dhcp.cox.net","subject":"Re: Worrisome bug trend","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-02-27T20:30:52Z","receivedAt":"2007-02-27T20:30:52Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 27 Feb 2007, Junio C Hamano wrote:\n\n> 75b62b48 (combine-diff broken cast)\n> \te702496e Aug 23 2006 (memcpy->hashcpy)\n> \tfunny thing is that another similar cast is correct.\n> \n> Johannes Schindelin.\n\n... while working on some diff --no-index code. (Strangely enough.)\n\nCiao,\nDscho\n"},{"id":"35672","messageId":"87vehn2v0f.fsf@wine.dyndns.org","threadId":"6989","inReplyTo":"7vzm6zcpv0.fsf@assigned-by-dhcp.cox.net","subject":"Re: Worrisome bug trend","fromName":"Alexandre Julliard","fromEmail":"julliard@winehq.org","sentAt":"2007-02-27T20:41:36Z","receivedAt":"2007-02-27T20:41:36Z","isPatch":false,"sender":{"key":"julliard@winehq.org","avatar":null},"body":"Junio C Hamano writes:\n\n> 20276889 (daemon socksetup() does not set FD_CLOEXEC)\n> \ta87e8be2 Jul 13 2005\n>\n> Alex Julliard.\n\n... by noticing breakage when upgrading to 1.5.0.\n\n-- \nAlexandre Julliard\njulliard@winehq.org\n"},{"id":"35673","messageId":"7vodnfcoy1.fsf@assigned-by-dhcp.cox.net","threadId":"6989","inReplyTo":"45E493D3.7060407@vilain.net","subject":"Re: Worrisome bug trend","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-27T20:42:30Z","receivedAt":"2007-02-27T20:42:30Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sam Vilain writes:\n\n> Junio C Hamano wrote:\n>> I take that as a sign that git hasn't been exercised well and\n>> yet more ancient bugs are sleeping, waiting to be triggered, not\n>> as a sign that we are very careful and adding only small number\n>> of risky new code in the releases.\n>> \n>\n> No! It's a sign that there aren't enough tests :)\n>\n> Maybe investigate the coverage of the test suite?\n\nI know we cover most of the success (expected) cases for things\nwe care about, but at the same time I personally find that tests\nfor failure cases (insane input, dataset expected to fail) are\nmissing.\n\nWe do not need investigation. We need a volunteer.\n\nAnd perhaps a new patch/feature acceptance criteria that\nrequires both expected behaviour and expected failure tests, but\nI am lazy ;-).\n"},{"id":"35680","messageId":"Pine.LNX.4.63.0702272143340.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6989","inReplyTo":"7vodnfcoy1.fsf@assigned-by-dhcp.cox.net","subject":"Re: Worrisome bug trend","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-02-27T20:44:51Z","receivedAt":"2007-02-27T20:44:51Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 27 Feb 2007, Junio C Hamano wrote:\n\n> Sam Vilain writes:\n> \n> > Junio C Hamano wrote:\n> >> I take that as a sign that git hasn't been exercised well and\n> >> yet more ancient bugs are sleeping, waiting to be triggered, not\n> >> as a sign that we are very careful and adding only small number\n> >> of risky new code in the releases.\n> >> \n> >\n> > No! It's a sign that there aren't enough tests :)\n> >\n> > Maybe investigate the coverage of the test suite?\n> \n> I know we cover most of the success (expected) cases for things\n> we care about, but at the same time I personally find that tests\n> for failure cases (insane input, dataset expected to fail) are\n> missing.\n> \n> We do not need investigation. We need a volunteer.\n\nMaybe a Summer of Code project?\n\n> And perhaps a new patch/feature acceptance criteria that requires both \n> expected behaviour and expected failure tests, but I am lazy ;-).\n\nI think that's okay. Many, many new features and bug fixes come with \ntests. I think that we do not have _few_ tests. At least not comparing to \nother projects (especially commercial ones...).\n\nCiao,\nDscho\n"},{"id":"35685","messageId":"200702272207.10453.robin.rosenberg.lists@dewire.com","threadId":"6989","inReplyTo":"7vodnfg4sy.fsf@assigned-by-dhcp.cox.net","subject":"Re: Worrisome bug trend","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2007-02-27T21:07:10Z","receivedAt":"2007-02-27T21:07:10Z","isPatch":false,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"tisdag 27 februari 2007 13:31 skrev Junio C Hamano:\n> I was reviewing the bugs we fixed since v1.5.0 and noticed\n> almost all of them are ancient ones. We do have small number of\n> bugs introduced by recently added commands and options, but I\n> see quite a few that are from 2005.\n> \n> I take that as a sign that git hasn't been exercised well and\n> yet more ancient bugs are sleeping, waiting to be triggered, not\n> as a sign that we are very careful and adding only small number\n> of risky new code in the releases.\n> \n> Which is kind of depressing...\n\nWhen bugs gets fixed and reappear, that's the time to start worry. That old \nbugs gets fixed is a very good sign. It means Git is being tested by users \nthat care. Git is very feature rich and considering that, it's amazing that \nis isn't completly bugridden with a 10K known unfixed bugs. That would be \ndepressing, the current state isn't.\n\n-- robin\n"},{"id":"35688","messageId":"20070227213049.GA6505@basalt.office.altlinux.org","threadId":"6989","inReplyTo":"7vzm6zcpv0.fsf@assigned-by-dhcp.cox.net","subject":"Re: Worrisome bug trend","fromName":"Dmitry V. Levin","fromEmail":"ldv@altlinux.org","sentAt":"2007-02-27T21:30:49Z","receivedAt":"2007-02-27T21:30:49Z","isPatch":false,"sender":{"key":"ldv@altlinux.org","avatar":"https://avatars.githubusercontent.com/u/5281408?v=4"},"body":"On Tue, Feb 27, 2007 at 12:22:43PM -0800, Junio C Hamano wrote:\n[...]\n> 8ab40a20 (show-ref --verify)\n> \t26cdd1e7 Dec 17 2006\n> \n> Dmitry V Levin.\n\n... while playing with new utilities (introduced after v1.4.4.x).\n\n\n-- \nldv\n"},{"id":"36146","messageId":"esambr$a8f$1@sea.gmane.org","threadId":"6989","inReplyTo":"7vzm6zcpv0.fsf@assigned-by-dhcp.cox.net","subject":"Re: Worrisome bug trend","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-03-03T02:28:27Z","receivedAt":"2007-03-03T02:28:27Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n> 50892777 (diff --git a//etc/inittab)\n>         65056021 Apr 28 2006 (first built-in diff)\n> \n> Me, while looking at recent \"diff --no-index\" series, by noticing\n> breakage. \n\nBy the way, I'm not sure if it is _not_ an error, a way to distinguish\nbetween in-tree path that begins from top of repository, and absolute\nout of tree path which beings in root '/'. But perhaps\n/etc/inittab instead of a//etc/inttab or a/etc/inittab would be better.\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"}]}