{"thread":{"id":"9124","subject":"gitk problems: can't unset \"idinlist(...)\"","startedAt":"2007-07-20T23:05:54Z","lastAt":"2007-07-21T11:42:27Z","messageCount":15,"participants":["Linus Torvalds","Jeff King","Junio C Hamano","David Kastrup","Paul Mackerras"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"47998","messageId":"alpine.LFD.0.999.0707201554540.27249@woody.linux-foundation.org","threadId":"9124","inReplyTo":null,"subject":"gitk problems: can't unset \"idinlist(...)\"","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-07-20T23:05:54Z","receivedAt":"2007-07-20T23:05:54Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\nOk, color me stumped, but gitk is unhappy.\n\nIngo and Thomas have just announced that they  have a unified x86 tree for \nboth i386/x86-64, so I did\n\n\tgitk arch/i386 arch/x86_64\n\nto look at what has happened recently in the kernel in that area.\n\nI get the gitk history view, but no actual diffs, and I get an application \nerror window saying\n\n\tcan't unset \"idinlist(57d1c91fa6d9146b309b7511f6432dea2a24858b)\": no such element in array\n\tcan't unset \"idinlist(57d1c91fa6d9146b309b7511f6432dea2a24858b)\": no such element in array\n\t    while executing\n\t\"unset idinlist($id)\"\n\t    (procedure \"layouttail\" line 11)\n\t    invoked from within\n\t\"layouttail\"\n\t    (procedure \"layoutmore\" line 35)\n\t    invoked from within\n\t\"layoutmore $tlimit $allread\"\n\t    (procedure \"chewcommits\" line 9)\n\t    invoked from within\n\t\"chewcommits 1\"\n\t    (\"eval\" body line 1)\n\t    invoked from within\n\t\"eval $script\"\n\t    (procedure \"dorunq\" line 9)\n\t    invoked from within\n\t\"dorunq\"\n\t    (\"after\" script)\n\nwhich really doesn't tell me much.\n\nIt doesn't seem to happen without path limiting, and it also doesn't seem \nto happen for all paths (doing \"gitk drivers/scsi\" doesn't show it), but \nsomehow that \"arch/i386\" part seems to bring it out.\n\nI'm not seeing anything interesting or special about that named commit, or \nanything else that would make gitk unhappy. But it is.\n\nCurrent kernel tree. Anybody else has any ideas? Somebody who knows \ntcl/tk, and gitk?\n\n\t\t\tLinus\n"},{"id":"48009","messageId":"20070721050912.GB20622@coredump.intra.peff.net","threadId":"9124","inReplyTo":"alpine.LFD.0.999.0707201554540.27249@woody.linux-foundation.org","subject":"Re: gitk problems: can't unset \"idinlist(...)\"","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-07-21T05:09:12Z","receivedAt":"2007-07-21T05:09:12Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Jul 20, 2007 at 04:05:54PM -0700, Linus Torvalds wrote:\n\n> \tcan't unset \"idinlist(57d1c91fa6d9146b309b7511f6432dea2a24858b)\": no such element in array\n> [...]\n> I'm not seeing anything interesting or special about that named commit, or \n> anything else that would make gitk unhappy. But it is.\n\nInterestingly, I repeatably get the exact same error but with a\ndifferent commit:\n\n  7ed40918a386afc2e14a6d3da563ea6d13686c25\n\nwhich looks like a totally uninteresting commit.\n\nI would expect, given that our repositories are at presumably the same\nstate, that we would get the same error at the same spot, but we don't.\nWhich implies to me there is some randomness, except that I get the\n_same_ commit every time (and presumably so do you).\n\nMy master (and all other branches) are at c2e6805.\n\n-Peff\n"},{"id":"48012","messageId":"alpine.LFD.0.999.0707202226130.27249@woody.linux-foundation.org","threadId":"9124","inReplyTo":"20070721050912.GB20622@coredump.intra.peff.net","subject":"Re: gitk problems: can't unset \"idinlist(...)\"","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-07-21T05:53:10Z","receivedAt":"2007-07-21T05:53:10Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 21 Jul 2007, Jeff King wrote:\n> \n> Interestingly, I repeatably get the exact same error but with a\n> different commit:\n> \n>   7ed40918a386afc2e14a6d3da563ea6d13686c25\n> \n> which looks like a totally uninteresting commit.\n\nIt seems to depend on the path limiter.\n\nWith \"arch/i386\", I get the 7ed409 one, with \"arch/i386 arch/x86_64\" I get \na complaint about 57d1c91fa. In neither case do I see the reason.\n\nBut I think I found a clue. One thing special about that 57d1c91fa is that \nwhen you do\n\n\tgit log --topo-order --parents --pretty=one arch/i386/ arch/x86_64/\n\nand search for it, it first shows up as a parent for commit 9fdb62af92: \nand not just _one_ parent, but three! So it looks like the parent \nsimplification is broken, and maybe gitk is unhappy for that reason.\n\nThe same is true of 7ed40918a38, btw, so yeah, I think that's it.\n\nJunio, didn't we have some parent simplification patches recently?\n\n\t\t\tLinus\n"},{"id":"48013","messageId":"7vfy3iwb88.fsf@assigned-by-dhcp.cox.net","threadId":"9124","inReplyTo":"alpine.LFD.0.999.0707202226130.27249@woody.linux-foundation.org","subject":"Re: gitk problems: can't unset \"idinlist(...)\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-07-21T05:56:55Z","receivedAt":"2007-07-21T05:56:55Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds <torvalds@linux-foundation.org> writes:\n\n> It seems to depend on the path limiter.\n>\n> With \"arch/i386\", I get the 7ed409 one, with \"arch/i386 arch/x86_64\" I get \n> a complaint about 57d1c91fa. In neither case do I see the reason.\n>\n> But I think I found a clue. One thing special about that 57d1c91fa is that \n> when you do\n>\n> \tgit log --topo-order --parents --pretty=one arch/i386/ arch/x86_64/\n>\n> and search for it, it first shows up as a parent for commit 9fdb62af92: \n> and not just _one_ parent, but three! So it looks like the parent \n> simplification is broken, and maybe gitk is unhappy for that reason.\n\nYeah, I think if you limit the range at the bottom\n(e.g. v2.6.21..)  the problem disappears.\n\n> The same is true of 7ed40918a38, btw, so yeah, I think that's it.\n>\n> Junio, didn't we have some parent simplification patches recently?\n\nWe had a patch to remove duplicated parent or something, I\nthink.\n"},{"id":"48014","messageId":"20070721055918.GA22399@coredump.intra.peff.net","threadId":"9124","inReplyTo":"alpine.LFD.0.999.0707202226130.27249@woody.linux-foundation.org","subject":"Re: gitk problems: can't unset \"idinlist(...)\"","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-07-21T05:59:18Z","receivedAt":"2007-07-21T05:59:18Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Jul 20, 2007 at 10:53:10PM -0700, Linus Torvalds wrote:\n\n> With \"arch/i386\", I get the 7ed409 one, with \"arch/i386 arch/x86_64\" I get \n> a complaint about 57d1c91fa. In neither case do I see the reason.\n\nOops, I thought you were using a different command line.\n\n> \tgit log --topo-order --parents --pretty=one arch/i386/ arch/x86_64/\n> \n> and search for it, it first shows up as a parent for commit 9fdb62af92: \n> and not just _one_ parent, but three! So it looks like the parent \n> simplification is broken, and maybe gitk is unhappy for that reason.\n\nOK, that should make it easier to find (note also that 9fdb62af92 is an\noctopus, which might be related).\n\n> Junio, didn't we have some parent simplification patches recently?\n\nv1.5.2 works, so I am bisecting.\n\n-Peff\n"},{"id":"48015","messageId":"20070721060600.GA29820@coredump.intra.peff.net","threadId":"9124","inReplyTo":"20070721055918.GA22399@coredump.intra.peff.net","subject":"Re: gitk problems: can't unset \"idinlist(...)\"","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-07-21T06:06:00Z","receivedAt":"2007-07-21T06:06:00Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Jul 21, 2007 at 01:59:18AM -0400, Jeff King wrote:\n\n> v1.5.2 works, so I am bisecting.\n\nHmm. The bad commit is 1ed84157. The commit message is a very suspicious\n\"Revert 88494423 (removal of duplicate parents in the output codepath).\"\n\n-Peff\n"},{"id":"48016","messageId":"alpine.LFD.0.999.0707202304350.27249@woody.linux-foundation.org","threadId":"9124","inReplyTo":"alpine.LFD.0.999.0707202226130.27249@woody.linux-foundation.org","subject":"Re: gitk problems: can't unset \"idinlist(...)\"","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-07-21T06:11:19Z","receivedAt":"2007-07-21T06:11:19Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 20 Jul 2007, Linus Torvalds wrote:\n> \n> Junio, didn't we have some parent simplification patches recently?\n\nYeah. Junio, I think your 11d6596709e04b8d2b429f230b2ed570d013f812 is \nbuggy.\n\nHere's a patch. Not very well tested, but it makes gitk happy and passes \nall the tests. And I really think Junio's code was very dubious (it did \nthat \"p = p->next\" *every* time, and then did \"pp = &p->next\", so \"pp\" \nwould end up jumping by multiple entries.\n\nThe new code only ever changes \"pp\" - either by moving p->next into it \n(delete the current entry) or by moving pp forward by one (keep the \ncurrent entry).\n\nThat's much more logical, but somebody should double-check me anyway.\n\n\t\tLinus\n\n---\nSubject: Fix up duplicate parents removal\n\nThis removes duplicate parents properly, making gitk happy again.\n\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\n---\n revision.c |   11 ++++++-----\n 1 files changed, 6 insertions(+), 5 deletions(-)\n\ndiff --git a/revision.c b/revision.c\nindex 28b5f2e..7036cf2 100644\n--- a/revision.c\n+++ b/revision.c\n@@ -1323,16 +1323,17 @@ static enum rewrite_result rewrite_one(struct rev_info *revs, struct commit **pp\n \n static void remove_duplicate_parents(struct commit *commit)\n {\n-\tstruct commit_list *p;\n-\tstruct commit_list **pp = &commit->parents;\n+\tstruct commit_list **pp, *p;\n \n \t/* Examine existing parents while marking ones we have seen... */\n-\tfor (p = commit->parents; p; p = p->next) {\n+\tpp = &commit->parents;\n+\twhile ((p = *pp) != NULL) {\n \t\tstruct commit *parent = p->item;\n-\t\tif (parent->object.flags & TMP_MARK)\n+\t\tif (parent->object.flags & TMP_MARK) {\n+\t\t\t*pp = p->next;\n \t\t\tcontinue;\n+\t\t}\n \t\tparent->object.flags |= TMP_MARK;\n-\t\t*pp = p;\n \t\tpp = &p->next;\n \t}\n \t/* ... and clear the temporary mark */\n"},{"id":"48017","messageId":"20070721061857.GB29820@coredump.intra.peff.net","threadId":"9124","inReplyTo":"alpine.LFD.0.999.0707202304350.27249@woody.linux-foundation.org","subject":"Re: gitk problems: can't unset \"idinlist(...)\"","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-07-21T06:18:57Z","receivedAt":"2007-07-21T06:18:57Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Jul 20, 2007 at 11:11:19PM -0700, Linus Torvalds wrote:\n\n> Here's a patch. Not very well tested, but it makes gitk happy and passes \n> all the tests. And I really think Junio's code was very dubious (it did \n> that \"p = p->next\" *every* time, and then did \"pp = &p->next\", so \"pp\" \n> would end up jumping by multiple entries.\n\nI just independently came to the same conclusion. Your patch looks\ncorrect to me (though there are some unrelated formatting changes which\nmade it a little harder to read).\n\nAcked-by: Jeff King <peff@peff.net>\n\n-Peff\n"},{"id":"48018","messageId":"20070721062448.GA8722@coredump.intra.peff.net","threadId":"9124","inReplyTo":"20070721061857.GB29820@coredump.intra.peff.net","subject":"Re: gitk problems: can't unset \"idinlist(...)\"","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-07-21T06:24:48Z","receivedAt":"2007-07-21T06:24:48Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Jul 21, 2007 at 02:18:57AM -0400, Jeff King wrote:\n\n> correct to me (though there are some unrelated formatting changes which\n> made it a little harder to read).\n\nBy which I mean you can keep the 'for' loop, since in either case we are\nalways reading p->next (if we skip, then we set *pp to p->next anyway,\nand if we don't, then pp becomes a pointer to p->next).\n\nSo this is a more readable patch which I believe is equivalent.\n\n---\ndiff --git a/revision.c b/revision.c\nindex 28b5f2e..7def867 100644\n--- a/revision.c\n+++ b/revision.c\n@@ -1329,10 +1329,11 @@ static void remove_duplicate_parents(struct commit *commit)\n \t/* Examine existing parents while marking ones we have seen... */\n \tfor (p = commit->parents; p; p = p->next) {\n \t\tstruct commit *parent = p->item;\n-\t\tif (parent->object.flags & TMP_MARK)\n+\t\tif (parent->object.flags & TMP_MARK) {\n+\t\t\t*pp = p->next;\n \t\t\tcontinue;\n+\t\t}\n \t\tparent->object.flags |= TMP_MARK;\n-\t\t*pp = p;\n \t\tpp = &p->next;\n \t}\n \t/* ... and clear the temporary mark */\n"},{"id":"48019","messageId":"alpine.LFD.0.999.0707202329220.27249@woody.linux-foundation.org","threadId":"9124","inReplyTo":"20070721061857.GB29820@coredump.intra.peff.net","subject":"Re: gitk problems: can't unset \"idinlist(...)\"","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-07-21T06:34:02Z","receivedAt":"2007-07-21T06:34:02Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 21 Jul 2007, Jeff King wrote:\n> \n> I just independently came to the same conclusion. Your patch looks\n> correct to me (though there are some unrelated formatting changes which\n> made it a little harder to read).\n\nYeah, I shouldn't have done that - I just ended up changing the \"for()\" to \na \"while()\" (because we should *not* do the same thing at the end of the \nloop each time).  And as a part of that I changed the initialization to be \nat the head of the while-loop rather than in the variable declaration, \nbecause that's how I tend to mostly write while-loops.\n\nBut I probably should have tried to keep the patch minimal instead, so \nthat it would show the changes better. Probably not a big deal.\n\n\t\tLinus\n"},{"id":"48020","messageId":"alpine.LFD.0.999.0707202335570.27249@woody.linux-foundation.org","threadId":"9124","inReplyTo":"20070721062448.GA8722@coredump.intra.peff.net","subject":"Re: gitk problems: can't unset \"idinlist(...)\"","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-07-21T06:47:24Z","receivedAt":"2007-07-21T06:47:24Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 21 Jul 2007, Jeff King wrote:\n> \n> By which I mean you can keep the 'for' loop, since in either case we are\n> always reading p->next (if we skip, then we set *pp to p->next anyway,\n> and if we don't, then pp becomes a pointer to p->next).\n> \n> So this is a more readable patch which I believe is equivalent.\n\nFair enough, that also works.\n\nAnyway, just because this is actually something I've noticed a lot of \npeople do wrong, I actually do tend to think that when you traverse a \nsingly-linked list and remove entries, you should *never* traverse the \nlist itself, you should only ever traverse the \"pointer to the pointer\".\n\nSo the difference between your version and mine is that the\n\n\twhile ((p = *pp) != NULL)\n\nmodel really only has one single \"iterator variable\": \"pp\". Which makes it \na lot easier to think about and avoid problems.\n\nIn contrast, your for-loop actually keeps track of *two* independent \nvariables, the \"tail pointer of the list we're building up\" (pp) and the \n\"head pointer of the old list we're traversing\" (p).\n\nDoes it work? Yes. But I tend to prefer the \"there's a single list\" model, \nwhere you just remove entries as you traverse it through a single indirect \npointer.\n\nThey're certainly equivalent, but slightly different mindsets. I at least \npersonally find the \"single pointer\" less likely to have problems, because \nyou can never get out of sync (which was basically exactly the problem \nthat Junio's code had), because there is nothing to get out of sync _with_ \nwhen you just have a single main iterator variable.\n\n\t\t\tLinus\n"},{"id":"48021","messageId":"20070721065405.GA9793@coredump.intra.peff.net","threadId":"9124","inReplyTo":"alpine.LFD.0.999.0707202335570.27249@woody.linux-foundation.org","subject":"Re: gitk problems: can't unset \"idinlist(...)\"","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-07-21T06:54:05Z","receivedAt":"2007-07-21T06:54:05Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Jul 20, 2007 at 11:47:24PM -0700, Linus Torvalds wrote:\n\n> So the difference between your version and mine is that the\n> \n> \twhile ((p = *pp) != NULL)\n\nI actually like your version better (I like saving for loops for\nhonest-to-god, for-each-element-in-this-list iteration; munging the list\nin the middle is something that you _should_ call attention to). I just\nfound your patch much harder to verify, because I had to make sure the\nfor/while change was equivalent. So you can blame Junio for writing it\nwrong in the first place. :)\n\nJunio, whatever you apply, please credit Linus; he beat me to the fix\nand so my patch is completely cribbed from his. :)\n\n-Peff\n"},{"id":"48027","messageId":"85k5su9k59.fsf_-_@lola.goethe.zz","threadId":"9124","inReplyTo":"alpine.LFD.0.999.0707202335570.27249@woody.linux-foundation.org","subject":"pointer to pointer (was: gitk problems: can't unset \"idinlist(...)\")","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-07-21T09:32:50Z","receivedAt":"2007-07-21T09:32:50Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Linus Torvalds <torvalds@linux-foundation.org> writes:\n\n> Anyway, just because this is actually something I've noticed a lot\n> of people do wrong, I actually do tend to think that when you\n> traverse a singly-linked list and remove entries, you should *never*\n> traverse the list itself, you should only ever traverse the \"pointer\n> to the pointer\".\n\nWhen I have doubly-linked lists where there is only forward traversal\n(the backlink being for convenient deletions without context), I make\nthe backlink a pointer to pointer.  This also means that one can\nremove at the front of the list without needing to know the head\nseparately.\n\nAnyway, here is some really, really ancient code of mine (file date is\nof 1990 but it's older than that) which sorts linked lists stably\nwithout extra storage and makes heavy use of pointer to pointer\ntraversal in both code and interface.  There is also a strictly\nnon-recursive variant with the same data flow (except for never making\na redundant assignment) and just one instead of two functions which\nconsistently beats good qsort implementations, but this old version is\nquite more fun to read.\n\nBasically, if head is the pointer to a sorted list of at least n\nelements, mergesort(&head, n) will sort the first n elements and\nreturn a pointer to that link which contains the tail of the list.  So\nif you did not already 0-terminate your list, *mergesort(&head,n)=0;\nwill both sort and terminate your list.\n\n\n\n#include \"mergesrt.h\"\nint (*mergecompare)(void *p1, void *p2);\nint mergelink;\n#define getlink(adr) (*(void**)((char*)(adr)+mergelink))\n\nstatic void **merge(void **head1, void **tail1, void **tail2, unsigned n1, unsigned n2)\n{\n\tregister void *p1 = *head1, *p2 = *tail1;\n\tfor(;;) {\n\t\tif ((*mergecompare)(p1, p2) <= 0) {\n\t\t\tp1 = *(head1 = &getlink(*head1 = p1));\n\t\t\tif (--n1 == 0)\n\t\t\t\treturn *head1 = p2, tail2;\n\t\t} else {\n\t\t\tp2 = *(head1 = &getlink(*head1 = p2));\n\t\t\tif (--n2 == 0)\n\t\t\t\treturn *tail1 = p2, *head1 = p1, tail1;\n\t\t}\n\t}\n}\n\n\nvoid **mergesort(void **head, unsigned n)\n{\n\tswitch (n) {\n\tcase 0:\n\t\treturn head;\n\tcase 1:\n\t\treturn &getlink(*head);\n\tcase 2:\n\t\t{\n\t\t\tregister void *p1, *p2;\n\n\t\t\tp2 = getlink(p1 = *head);\n\t\t\tif ((*mergecompare)(p1, p2) <= 0)\n\t\t\t\treturn &getlink(p2);\n\t\t\tgetlink(p1) = getlink(*head=p2);\n\t\t\treturn &getlink(getlink(p2) = p1);\n\t\t}\n\tdefault:\n\t\t{\n\t\t\tunsigned m;\n\t\t\tvoid **h2;\n\t\t\tn -= m = n / 2;\n\t\t\th2 = mergesort(head, n);\n\t\t\treturn merge(head,h2,mergesort(h2,m),n,m);\n\t\t}\n\t}\n}\n\n\n\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"48028","messageId":"85bqe69jmd.fsf@lola.goethe.zz","threadId":"9124","inReplyTo":"85k5su9k59.fsf_-_@lola.goethe.zz","subject":"Re: pointer to pointer","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-07-21T09:44:10Z","receivedAt":"2007-07-21T09:44:10Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"David Kastrup <dak@gnu.org> writes:\n\n    Content-Type: text/x-csrc\n    Content-Disposition: attachment\n    Content-Description: Stable Mergesort on linked lists\n\nSorry, this was supposed to be inline.  I apologize for the\ninconvenience.\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"48029","messageId":"18081.61731.641169.306397@cargo.ozlabs.ibm.com","threadId":"9124","inReplyTo":"alpine.LFD.0.999.0707201554540.27249@woody.linux-foundation.org","subject":"Re: gitk problems: can't unset \"idinlist(...)\"","fromName":"Paul Mackerras","fromEmail":"paulus@samba.org","sentAt":"2007-07-21T11:42:27Z","receivedAt":"2007-07-21T11:42:27Z","isPatch":false,"sender":{"key":"paulus@samba.org","avatar":"https://avatars.githubusercontent.com/u/1606439?v=4"},"body":"Linus Torvalds writes:\n\n> Somebody who knows \n> tcl/tk, and gitk?\n\nThat sounds like me. :)  I see from the following messages that the\nbug turned out to be elsewhere in git, but it looks like gitk should\nbe more robust and do something sensible rather than just throwing a\nTcl error.  I'll look at it.\n\nPaul.\n"}]}