{"thread":{"id":"26231","subject":"problem with cherry-picking a commit which comes before introducing a new submodule","startedAt":"2011-01-07T17:24:32Z","lastAt":"2011-01-18T16:20:23Z","messageCount":10,"participants":["Yaroslav Halchenko","Jonathan Nieder","Andreas Ericsson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"159118","messageId":"20110107172432.GA6040@onerussian.com","threadId":"26231","inReplyTo":null,"subject":"problem with cherry-picking a commit which comes before introducing a new submodule","fromName":"Yaroslav Halchenko","fromEmail":"debian@onerussian.com","sentAt":"2011-01-07T17:24:32Z","receivedAt":"2011-01-07T17:24:32Z","isPatch":false,"sender":{"key":"debian@onerussian.com","avatar":"https://gravatar.com/avatar/9d2f005048a0274a9c26bc47a51f580e2bf631dfedfdb18370f65e08e4250317?d=mp&s=160"},"body":"Hi GIT Gurus,\n\nper quick IRC troubleshooting it seems to be some kind of an issue in\ngit cherry-pick logic which tries to deal with existing .gitmodules\nstructure?\n\nIn our repository we had some submodules, then there was a branch off\n(call new branch todonotloose) with a single commit.  In the master we\nhad some other commits and moved one of the subdirectories into a\nsubmodule.\n\nLater on we decided to cherry pick todonotloose into master but\ncherry-pick fails despite the fact that 'git show todonotloose | patch\n-p1' applies just fine, ie there were no changes touching any of the\nsubmodules.\n\nSee http://pastebin.com/hpqbiB03 for output.\n\nIMHO everything is legit and failure should have not occurred, or am I\nmissing something?\n\n-- \nYaroslav O. Halchenko\nPostdoctoral Fellow,   Department of Psychological and Brain Sciences\nDartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755\nPhone: +1 (603) 646-9834                       Fax: +1 (603) 646-1419\nWWW:   http://www.linkedin.com/in/yarik        \n"},{"id":"159124","messageId":"20110107181501.GA28980@burratino","threadId":"26231","inReplyTo":"20110107172432.GA6040@onerussian.com","subject":"Re: problem with cherry-picking a commit which comes before introducing a new submodule","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-01-07T18:15:01Z","receivedAt":"2011-01-07T18:15:01Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"(+cc: Elijah Newren, who has worked on some of this code)\n\nYaroslav Halchenko wrote:\n\n> In our repository we had some submodules, then there was a branch off\n> (call new branch todonotloose) with a single commit.  In the master we\n> had some other commits and moved one of the subdirectories into a\n> submodule.\n> \n> Later on we decided to cherry pick todonotloose into master but\n> cherry-pick fails despite the fact that 'git show todonotloose | patch\n> -p1' applies just fine, ie there were no changes touching any of the\n> submodules.\n[...]\n> $> git status\n> # On branch master\n> # Changes to be committed:\n> #   (use \"git reset HEAD <file>...\" to unstage)\n> #\n> #\tnew file:   poster-hbm2011_neurodebian/abstract.txt\n> #\tmodified:   poster-hbm2011_neurodebian/jb.txt\n> #\n> # Unmerged paths:\n> #   (use \"git reset HEAD <file>...\" to unstage)\n> #   (use \"git add/rm <file>...\" as appropriate to mark resolution)\n> #\n> #\tadded by us:        frontiers/code\n> #\n\nAs contrib/examples/git-revert.sh explains, the heart of \"git\ncherry-pick\" is\n\n\tbase=todonotloose^\n\tnext=todonotloose\n\thead=HEAD\n\n\tgit merge-recursive $base -- $head $next\n\nCould you try that, perhaps with GIT_MERGE_VERBOSITY=4 (or some other\nnumber from 1 to 5, larger is louder) in the environment?  For context,\n\n\tgit ls-files -u;\t# after the merge\n\tgit diff-tree todonotloose\n\tgit diff-tree todonotloose^ HEAD\n\nwould also be interesting.\n"},{"id":"159127","messageId":"20110107183226.GG6040@onerussian.com","threadId":"26231","inReplyTo":"20110107181501.GA28980@burratino","subject":"Re: problem with cherry-picking a commit which comes before introducing a new submodule","fromName":"Yaroslav Halchenko","fromEmail":"debian@onerussian.com","sentAt":"2011-01-07T18:32:26Z","receivedAt":"2011-01-07T18:32:26Z","isPatch":false,"sender":{"key":"debian@onerussian.com","avatar":"https://gravatar.com/avatar/9d2f005048a0274a9c26bc47a51f580e2bf631dfedfdb18370f65e08e4250317?d=mp&s=160"},"body":"oy -- I thought that cherry-pick is primarily just application of the\npatch (without use of the merge clevernesses).\n\nHere is the protocol:\n% export GIT_MERGE_VERBOSITY=4\n%         base=todonotloose^\n%         next=todonotloose\n%         head=HEAD\n% \n%         git merge-recursive $base -- $head $next\nMerging HEAD with todonotloose\nMerging:\n855981d just placeholders in the abstract\na00c497 Initial draft for HBM abstract.\nCONFLICT (file/directory): There is a directory with name frontiers/code in todonotloose. Adding frontiers/code as frontiers/code~HEAD\n%         git ls-files -u;        # after the merge\n160000 a2b57871d2d79bef06ba6214739d82b9a63772a8 2   frontiers/code\nzsh: command not found: #\n%         git diff-tree todonotloose\na00c497fa399c00486c97121ed0b8fda72c7ce47\n:040000 040000 40427e34a1ff89c458f2a5f262a108d46b4fa004 c7ba91028b1cef63f4f7eef70f0c4054b31e92b6 M  poster-hbm2011_neurodebian\n%         git diff-tree todonotloose^ HEAD\n:100644 100644 378e1379ec5ebb7abac59fec162b7238b5846525 c39ced763aeb5fd352cecd6fef1bfc40471f2246 M  .gitmodules\n:000000 040000 0000000000000000000000000000000000000000 141dbc1bfe1be2eab77f04ca03f6f28feb372cca A  challenge-execpapers\n:040000 040000 401fd66867de412b8653dc3a698bbaa45441bec1 ee190f09786f324abdda6e7a36e8278c201a20a0 M  frontiers\n:040000 040000 26c884a67efb55bdf96d7453d9acd50cee36ae90 ad3e829d15b302c4342a6b2a9fb5dfede0ed77c9 M  sty\n\n\nOn Fri, 07 Jan 2011, Jonathan Nieder wrote:\n> As contrib/examples/git-revert.sh explains, the heart of \"git\n> cherry-pick\" is\n\n> \tbase=todonotloose^\n> \tnext=todonotloose\n> \thead=HEAD\n\n> \tgit merge-recursive $base -- $head $next\n\n> Could you try that, perhaps with GIT_MERGE_VERBOSITY=4 (or some other\n> number from 1 to 5, larger is louder) in the environment?  For context,\n\n> \tgit ls-files -u;\t# after the merge\n> \tgit diff-tree todonotloose\n> \tgit diff-tree todonotloose^ HEAD\n\n> would also be interesting.\n\n\n-- \nYaroslav O. Halchenko\nPostdoctoral Fellow,   Department of Psychological and Brain Sciences\nDartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755\nPhone: +1 (603) 646-9834                       Fax: +1 (603) 646-1419\nWWW:   http://www.linkedin.com/in/yarik        \n"},{"id":"159177","messageId":"20110107230017.GA15495@burratino","threadId":"26231","inReplyTo":"20110107183226.GG6040@onerussian.com","subject":"Re: problem with cherry-picking a commit which comes before introducing a new submodule","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-01-07T23:00:17Z","receivedAt":"2011-01-07T23:00:17Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Yaroslav Halchenko wrote [abbreviated]:\n\n> Merging HEAD with todonotloose\n> Merging:\n> 855981d just placeholders in the abstract\n> a00c497 Initial draft for HBM abstract.\n> CONFLICT (file/directory): There is a directory with name frontiers/code in todonotloose. Adding frontiers/code as\n> +frontiers/code~HEAD\n> %         git ls-files -u\n> 160000 a2b5787 2   frontiers/code\n> %         git diff-tree todonotloose\n> a00c497\n> :040000 040000 40427e34 c7ba910 M\tposter-hbm2011_neurodebian\n> %         git diff-tree todonotloose^ HEAD\n> :100644 100644 378e137 c39ced7 M\t.gitmodules\n> :000000 040000 0000000 141dbc1 A\tchallenge-execpapers\n> :040000 040000 401fd66 ee190f0 M\tfrontiers\n> :040000 040000 26c884a ad3e829 M\tsty\n\nOne more piece of protocol: what git version are you using?  The\nrelease notes mention a fix in this area in v1.7.3[1]:\n\n * \"git merge -s recursive\" (which is the default) did not handle cases\n   where a directory becomes a file (or vice versa) very well.\n\nHopefully this is that.  In any case, sounds like a bug.\n\n(Hopefully someone else can comment on why cherry-pick uses the\nmerge machinery to notice conflicts that would not be clear from\nthe patch alone.)\n\nThanks again.\nJonathan\n\n[1] There is an updated Debian source package at [2].  Or, probably\nfaster: one can use the build result in bin-wrappers/ from a git.git\nclone in place.\n[2] http://mentors.debian.net/debian/pool/main/g/git/git_1.7.4~rc1-0.1.dsc\n"},{"id":"159183","messageId":"20110107234841.GQ6040@onerussian.com","threadId":"26231","inReplyTo":"20110107230017.GA15495@burratino","subject":"Re: problem with cherry-picking a commit which comes before introducing a new submodule","fromName":"Yaroslav Halchenko","fromEmail":"debian@onerussian.com","sentAt":"2011-01-07T23:48:42Z","receivedAt":"2011-01-07T23:48:42Z","isPatch":false,"sender":{"key":"debian@onerussian.com","avatar":"https://gravatar.com/avatar/9d2f005048a0274a9c26bc47a51f580e2bf631dfedfdb18370f65e08e4250317?d=mp&s=160"},"body":"sorry -- lame me... 1.7.2.3 ... I will check with current version as soon as\nkids permit ;-)\n\n% apt-cache policy git\ngit:\n  Installed: 1:1.7.2.3-2.2\n  Candidate: 1:1.7.2.3-2.2\n  Version table:\n *** 1:1.7.2.3-2.2 0\n        900 http://debian.lcs.mit.edu/debian/ squeeze/main amd64 Packages\n        800 http://debian.lcs.mit.edu/debian/ sid/main amd64 Packages\n        100 /var/lib/dpkg/status\n% git --version\ngit version 1.7.2.3\n\n\nOn Fri, 07 Jan 2011, Jonathan Nieder wrote:\n> One more piece of protocol: what git version are you using?  The\n> release notes mention a fix in this area in v1.7.3[1]:\n\n>  * \"git merge -s recursive\" (which is the default) did not handle cases\n>    where a directory becomes a file (or vice versa) very well.\n\n> Hopefully this is that.  In any case, sounds like a bug.\n\n> (Hopefully someone else can comment on why cherry-pick uses the\n> merge machinery to notice conflicts that would not be clear from\n> the patch alone.)\n\n> Thanks again.\n> Jonathan\n\n> [1] There is an updated Debian source package at [2].  Or, probably\n> faster: one can use the build result in bin-wrappers/ from a git.git\n> clone in place.\n> [2] http://mentors.debian.net/debian/pool/main/g/git/git_1.7.4~rc1-0.1.dsc\n\n\n-- \n=------------------------------------------------------------------=\nKeep in touch                                     www.onerussian.com\nYaroslav Halchenko                 www.ohloh.net/accounts/yarikoptic\n"},{"id":"159186","messageId":"20110108000131.GR6040@onerussian.com","threadId":"26231","inReplyTo":"20110107230017.GA15495@burratino","subject":"Re: problem with cherry-picking a commit which comes before introducing a new submodule","fromName":"Yaroslav Halchenko","fromEmail":"debian@onerussian.com","sentAt":"2011-01-08T00:01:31Z","receivedAt":"2011-01-08T00:01:31Z","isPatch":false,"sender":{"key":"debian@onerussian.com","avatar":"https://gravatar.com/avatar/9d2f005048a0274a9c26bc47a51f580e2bf631dfedfdb18370f65e08e4250317?d=mp&s=160"},"body":"message is different -- result the same:\nI: writing typescript to /home/yoh/.tmp/script.git-cherry-pick.17386.20110107.1857 ...\n% git --version\ngit version 1.7.4.rc1\n% git reset --hard\nHEAD is now at 855981d just placeholders in the abstract\n% export GIT_MERGE_VERBOSITY=5\n% git cherry-pick todonotloose\nCONFLICT (file/directory): There is a directory with name frontiers/code in a00c497... Initial draft for HBM abstract.. Adding frontiers/code as frontiers/code~HEAD\nerror: could not apply a00c497... Initial draft for HBM abstract.\nhint: after resolving the conflicts, mark the corrected paths\nhint: with 'git add <paths>' or 'git rm <paths>'\nhint: and commit the result with 'git commit -c a00c497'\n% git status      \n# On branch master\n# Changes to be committed:\n#   (use \"git reset HEAD <file>...\" to unstage)\n#\n#   new file:   poster-hbm2011_neurodebian/abstract.txt\n#   modified:   poster-hbm2011_neurodebian/jb.txt\n#\n# Unmerged paths:\n#   (use \"git reset HEAD <file>...\" to unstage)\n#   (use \"git add/rm <file>...\" as appropriate to mark resolution)\n#\n#   added by us:        frontiers/code\n#\n% git reset --hard\nHEAD is now at 855981d just placeholders in the abstract\n%         base=todonotloose^\n%         next=todonotloose\n%         head=HEAD\n% \n%         git merge-recursive $base -- $head $next\nMerging HEAD with todonotloose\nMerging:\n855981d just placeholders in the abstract\na00c497 Initial draft for HBM abstract.\nfound 1 common ancestor(s):\n4708e24 minor moves around\nCONFLICT (file/directory): There is a directory with name frontiers/code in todonotloose. Adding frontiers/code as frontiers/code~HEAD\n%         git ls-files -u;        # after the merge\n160000 a2b57871d2d79bef06ba6214739d82b9a63772a8 2   frontiers/code\nzsh: command not found: #\n%         git diff-tree todonotloose\na00c497fa399c00486c97121ed0b8fda72c7ce47\n:040000 040000 40427e34a1ff89c458f2a5f262a108d46b4fa004 c7ba91028b1cef63f4f7eef70f0c4054b31e92b6 M  poster-hbm2011_neurodebian\n%         git diff-tree todonotloose^ HEAD\n:100644 100644 378e1379ec5ebb7abac59fec162b7238b5846525 c39ced763aeb5fd352cecd6fef1bfc40471f2246 M  .gitmodules\n:000000 040000 0000000000000000000000000000000000000000 141dbc1bfe1be2eab77f04ca03f6f28feb372cca A  challenge-execpapers\n:040000 040000 401fd66867de412b8653dc3a698bbaa45441bec1 ee190f09786f324abdda6e7a36e8278c201a20a0 M  frontiers\n:040000 040000 26c884a67efb55bdf96d7453d9acd50cee36ae90 ad3e829d15b302c4342a6b2a9fb5dfede0ed77c9 M  sty\n\n\n\nOn Fri, 07 Jan 2011, Jonathan Nieder wrote:\n\n> Yaroslav Halchenko wrote [abbreviated]:\n\n> > Merging HEAD with todonotloose\n> > Merging:\n> > 855981d just placeholders in the abstract\n> > a00c497 Initial draft for HBM abstract.\n> > CONFLICT (file/directory): There is a directory with name frontiers/code in todonotloose. Adding frontiers/code as\n> > +frontiers/code~HEAD\n> > %         git ls-files -u\n> > 160000 a2b5787 2   frontiers/code\n> > %         git diff-tree todonotloose\n> > a00c497\n> > :040000 040000 40427e34 c7ba910 M\tposter-hbm2011_neurodebian\n> > %         git diff-tree todonotloose^ HEAD\n> > :100644 100644 378e137 c39ced7 M\t.gitmodules\n> > :000000 040000 0000000 141dbc1 A\tchallenge-execpapers\n> > :040000 040000 401fd66 ee190f0 M\tfrontiers\n> > :040000 040000 26c884a ad3e829 M\tsty\n\n> One more piece of protocol: what git version are you using?  The\n> release notes mention a fix in this area in v1.7.3[1]:\n\n>  * \"git merge -s recursive\" (which is the default) did not handle cases\n>    where a directory becomes a file (or vice versa) very well.\n\n> Hopefully this is that.  In any case, sounds like a bug.\n\n> (Hopefully someone else can comment on why cherry-pick uses the\n> merge machinery to notice conflicts that would not be clear from\n> the patch alone.)\n\n> Thanks again.\n> Jonathan\n\n> [1] There is an updated Debian source package at [2].  Or, probably\n> faster: one can use the build result in bin-wrappers/ from a git.git\n> clone in place.\n> [2] http://mentors.debian.net/debian/pool/main/g/git/git_1.7.4~rc1-0.1.dsc\n\n\n-- \n=------------------------------------------------------------------=\nKeep in touch                                     www.onerussian.com\nYaroslav Halchenko                 www.ohloh.net/accounts/yarikoptic\n"},{"id":"159331","messageId":"20110111132710.GA14905@burratino","threadId":"26231","inReplyTo":"20110108000131.GR6040@onerussian.com","subject":"Re: problem with cherry-picking a commit which comes before introducing a new submodule","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-01-11T13:27:10Z","receivedAt":"2011-01-11T13:27:10Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Yaroslav Halchenko wrote [abbreviated]:\n\n> CONFLICT (file/directory): There is a directory with name frontiers/code in todonotloose. Adding frontiers/code as frontiers/code~HEAD\n> % git ls-files -u\n> 160000 a2b5787 2   frontiers/code\n> % git diff-tree todonotloose\n> a00c497\n> :040000 040000 40427e3 c7ba910 M  poster-hbm2011_neurodebian\n> % git diff-tree todonotloose^ HEAD\n> :100644 100644 378e137 c39ced7 M  .gitmodules\n> :000000 040000 0000000 141dbc1 A  challenge-execpapers\n> :040000 040000 401fd66 ee190f0 M  frontiers\n> :040000 040000 26c884a ad3e829 M  sty\n\nHere is what happens.\n\nIn the heart of merge_trees:\n\n\t/*\n\t * If there are D/F conflicts, and the paths currently exist\n\t * in the working copy as a file, remove them to make room\n\t * for the corresponding directory.  Such paths will later be\n\t * processed in process_df_entry() at the end.\n\t *\n\t * If the corresponding directory ends up being removed by the\n\t * merge, then the file will be reinstated at that time;\n\t * otherwise, if the file is not supposed to be removed by the\n\t * merge, the contents of the file will be placed in another\n\t * unique filename.\n\t */\n\tmake_room_for_directories_of_df_conflicts(o, entries);\n\nIn this case I suppose it is rather a directory/submodule conflict; in\nany case, there are no regular files involved, so this logic does not\nkick in and the directory is left alone.\n\nNext comes rename handling, which is irrelevant for our purposes.\n\nNext comes the per entry merge.\n\n\t/*\n\t * Per entry merge.  D/F conflicts are deferred so files\n\t * contained in such a directory can be resolved first.\n\t */\n\tfor (i = 0; i < entries->nr; i++) {\n\t\tconst char *path = entries->items[i].string;\n\t\tstruct stage_data *e = entries->items[i].util;\n\t\tif (!e->processed\n\t\t\t&& !process_entry(o, path, e))\n\t\t\tclean = 0;\n\t}\n\nThis is case B: \"added in one\" (like all directories, the\nfrontiers/code directory does not have an index entry, while the\nsubmodule does have one).  Since that path is in the current directory\nset, it is deferred for later processing.\n\nNext comes the per entry merge for D/F conflicts (process_df_entry in\nmerge-recursive.c).  This is the case \"directory -> (directory,\nfile)\".  Unfortunately the check that the old and new directories\nmatch is not implemented.  Even worse, git checks for a directory\n(which was not moved out of the way before) and does not realize that\na submodule might be another reason for a directory in the worktree.\nIn any event, we get a spurious conflict.\n\nThanks, that was interesting (no patch yet, alas).\n"},{"id":"159582","messageId":"20110118160222.GA23926@onerussian.com","threadId":"26231","inReplyTo":"20110111132710.GA14905@burratino","subject":"Re: problem with cherry-picking a commit which comes before introducing a new submodule","fromName":"Yaroslav Halchenko","fromEmail":"debian@onerussian.com","sentAt":"2011-01-18T16:02:22Z","receivedAt":"2011-01-18T16:02:22Z","isPatch":false,"sender":{"key":"debian@onerussian.com","avatar":"https://gravatar.com/avatar/9d2f005048a0274a9c26bc47a51f580e2bf631dfedfdb18370f65e08e4250317?d=mp&s=160"},"body":"\nOn Tue, 11 Jan 2011, Jonathan Nieder wrote:\n> ...\n> a submodule might be another reason for a directory in the worktree.\n> In any event, we get a spurious conflict.\n> Thanks, that was interesting (no patch yet, alas).\n\nis there a way to memorize this issue somewhere (bug tracking/TODO/etc)\nwhere this issue could be recorded so it doesn't get forgotten? ;)\n\n-- \nYaroslav O. Halchenko\nPostdoctoral Fellow,   Department of Psychological and Brain Sciences\nDartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755\nPhone: +1 (603) 646-9834                       Fax: +1 (603) 646-1419\nWWW:   http://www.linkedin.com/in/yarik        \n"},{"id":"159583","messageId":"4D35BAE1.6090204@op5.se","threadId":"26231","inReplyTo":"20110118160222.GA23926@onerussian.com","subject":"Re: problem with cherry-picking a commit which comes before introducing a new submodule","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2011-01-18T16:08:01Z","receivedAt":"2011-01-18T16:08:01Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"On 01/18/2011 05:02 PM, Yaroslav Halchenko wrote:\n> \n> On Tue, 11 Jan 2011, Jonathan Nieder wrote:\n>> ...\n>> a submodule might be another reason for a directory in the worktree.\n>> In any event, we get a spurious conflict.\n>> Thanks, that was interesting (no patch yet, alas).\n> \n> is there a way to memorize this issue somewhere (bug tracking/TODO/etc)\n> where this issue could be recorded so it doesn't get forgotten? ;)\n> \n\nIt will be stored in the hive-mind of the mailing list participants.\nIt's quite a bit better than it sounds actually.\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n\nConsidering the successes of the wars on alcohol, poverty, drugs and\nterror, I think we should give some serious thought to declaring war\non peace.\n"},{"id":"159584","messageId":"20110118162022.GX27814@onerussian.com","threadId":"26231","inReplyTo":"4D35BAE1.6090204@op5.se","subject":"Re: problem with cherry-picking a commit which comes before introducing a new submodule","fromName":"Yaroslav Halchenko","fromEmail":"debian@onerussian.com","sentAt":"2011-01-18T16:20:23Z","receivedAt":"2011-01-18T16:20:23Z","isPatch":false,"sender":{"key":"debian@onerussian.com","avatar":"https://gravatar.com/avatar/9d2f005048a0274a9c26bc47a51f580e2bf631dfedfdb18370f65e08e4250317?d=mp&s=160"},"body":"\nOn Tue, 18 Jan 2011, Andreas Ericsson wrote:\n> > is there a way to memorize this issue somewhere (bug tracking/TODO/etc)\n> > where this issue could be recorded so it doesn't get forgotten? ;)\n> It will be stored in the hive-mind of the mailing list participants.\n> It's quite a bit better than it sounds actually.\n\nok -- offload completed then, I am cleaning up my memory bank\n\n-- \n=------------------------------------------------------------------=\nKeep in touch                                     www.onerussian.com\nYaroslav Halchenko                 www.ohloh.net/accounts/yarikoptic\n"}]}