{"thread":{"id":"23138","subject":"git rev-list formatting","startedAt":"2010-03-22T11:30:57Z","lastAt":"2010-03-27T13:30:28Z","messageCount":14,"participants":["Eli Barzilay","Michael J Gruber","René Scharfe","Jeff King","Erik Faye-Lund","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"137541","messageId":"m3iq8opp8u.fsf@winooski.ccs.neu.edu","threadId":"23138","inReplyTo":null,"subject":"git rev-list formatting","fromName":"Eli Barzilay","fromEmail":"eli@barzilay.org","sentAt":"2010-03-22T11:30:57Z","receivedAt":"2010-03-22T11:30:57Z","isPatch":false,"sender":{"key":"eli@barzilay.org","avatar":"https://avatars.githubusercontent.com/u/185905?v=4"},"body":"Possible bug -- IIUC, this:\n\n git rev-list --pretty=\"%w(40,2,2)%b\" $rev\n\nshould show all bodies wrapped as specified, but with 1.7.0.3 I see\nonly the first one wrapped, and the rest don't show up. In one of my\nattempts to sort this, I saw all bodies, but all bodies after the\nfirst were not wrapped as specified.\n\nAlso, is there a way to avoid the \"commit \" line, print some\ninformation that I specify in the format string, and show the whole\nmessage as is (without wrapping or other tweaks)?\n\n-- \n ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:\n http://barzilay.org/ Maze is Life!\n"},{"id":"137543","messageId":"m3eijcpoud.fsf@winooski.ccs.neu.edu","threadId":"23138","inReplyTo":"m3iq8opp8u.fsf@winooski.ccs.neu.edu","subject":"Re: git rev-list formatting","fromName":"Eli Barzilay","fromEmail":"eli@barzilay.org","sentAt":"2010-03-22T11:39:38Z","receivedAt":"2010-03-22T11:39:38Z","isPatch":false,"sender":{"key":"eli@barzilay.org","avatar":"https://avatars.githubusercontent.com/u/185905?v=4"},"body":"Eli Barzilay writes:\n\n> [...]\n>\n> Also, is there a way to avoid the \"commit \" line, print some\n> information that I specify in the format string, and show the whole\n> message as is (without wrapping or other tweaks)?\n\nLooks like `git log' does something similar to what I want anyway,\nwhich leads me to a related question -- it's not clear to me what are\nthe differences between `git rev-list', `git log', `git diff', and\n`git show', since it looks like they can all be tweaked to produce\nsimilar outputs. Are they all the same with different outputs? Is\nthere some description of them with the differences explained?\n\nAlso related, it looks like `--abbrev-commit' has no effect on `git\nrev-list', but does on `git log', even through it's documented in the\nformer's man page. So it looks like either there are more\n(undocumented?) differences, or maybe that's also a bug?\n\n-- \n ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:\n http://barzilay.org/ Maze is Life!\n"},{"id":"137548","messageId":"4BA76BDF.6060106@drmicha.warpmail.net","threadId":"23138","inReplyTo":"m3eijcpoud.fsf@winooski.ccs.neu.edu","subject":"Re: git rev-list formatting","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2010-03-22T13:08:47Z","receivedAt":"2010-03-22T13:08:47Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Eli Barzilay venit, vidit, dixit 22.03.2010 12:39:\n> Eli Barzilay writes:\n> \n>> [...]\n>>\n>> Also, is there a way to avoid the \"commit \" line, print some\n>> information that I specify in the format string, and show the whole\n>> message as is (without wrapping or other tweaks)?\n> \n> Looks like `git log' does something similar to what I want anyway,\n> which leads me to a related question -- it's not clear to me what are\n> the differences between `git rev-list', `git log', `git diff', and\n> `git show', since it looks like they can all be tweaked to produce\n> similar outputs. Are they all the same with different outputs? Is\n> there some description of them with the differences explained?\n\nThe rev-list man page lists all commands of that family, with rev-list\nbeing the bare bones version, and log and friends being more \"high\nlevel\". log and rev-list walk the revision tree, show does not. Most of\nthat can be changed through options. whatchanged is a special family\nmember...\n\ndiff is from a completely different family (see git help diff or git\nhelp diffcore). It never walks, but compares revisions (or other things).\n\nThe log family never compares things, but can show a patch, i.e. the\ndifference to the ancestor(s).\n\n> Also related, it looks like `--abbrev-commit' has no effect on `git\n> rev-list', but does on `git log', even through it's documented in the\n> former's man page. So it looks like either there are more\n> (undocumented?) differences, or maybe that's also a bug?\n\nI consider this a bug. In fact, it has an effect, but not a visible one.\nYou would have to use --abbrev=7 or such.\n\nA patch is upcoming.\n\nCheers,\nMichael\n"},{"id":"137549","messageId":"b1b0f22cf3dc6d67f6094e761a1b7402b1471e97.1269264868.git.git@drmicha.warpmail.net","threadId":"23138","inReplyTo":"4BA76BDF.6060106@drmicha.warpmail.net","subject":"[PATCH] rev-list: heed --abbrev-commit option","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2010-03-22T13:36:30Z","receivedAt":"2010-03-22T13:36:30Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Currently, rev-list has a default of \"0\" for abbrev which means that\nswitching on abbreviations with --abbrev-commit has no visible effect,\neven though the option is documented.\n\nSet abbrev to DEFAULT_ABBREV so that --abbrev-commit has the same effect\nas for log.\n\nSigned-off-by: Michael J Gruber \nReported-by: Eli Barzilay \n---\nI'm actually wondering why log and rev-list don't share the relevant\npart of that code.\n\n builtin/rev-list.c | 2 +-\n 1 files changed, 1 insertions(+), 1 deletions(-)\n\ndiff --git a/builtin/rev-list.c b/builtin/rev-list.c\nindex 5679170..eb8e2c2 100644\n--- a/builtin/rev-list.c\n+++ b/builtin/rev-list.c\n@@ -313,7 +313,7 @@ int cmd_rev_list(int argc, const char **argv, const char *prefix)\n \n \tgit_config(git_default_config, NULL);\n \tinit_revisions(&revs, prefix);\n-\trevs.abbrev = 0;\n+\trevs.abbrev = DEFAULT_ABBREV;\n \trevs.commit_format = CMIT_FMT_UNSPECIFIED;\n \targc = setup_revisions(argc, argv, &revs, NULL);\n \n-- \n1.7.0.3.435.g097f4\n"},{"id":"137554","messageId":"m3aau0pgcy.fsf@winooski.ccs.neu.edu","threadId":"23138","inReplyTo":"4BA76BDF.6060106@drmicha.warpmail.net","subject":"Re: git rev-list formatting","fromName":"Eli Barzilay","fromEmail":"eli@barzilay.org","sentAt":"2010-03-22T14:42:53Z","receivedAt":"2010-03-22T14:42:53Z","isPatch":false,"sender":{"key":"eli@barzilay.org","avatar":"https://avatars.githubusercontent.com/u/185905?v=4"},"body":"Michael J Gruber writes:\n\n> The rev-list man page lists all commands of that family, with\n> rev-list being the bare bones version, and log and friends being\n> more \"high level\". log and rev-list walk the revision tree, show\n> does not. Most of that can be changed through options. whatchanged\n> is a special family member...\n>\n> diff is from a completely different family (see git help diff or git\n> help diffcore). It never walks, but compares revisions (or other things).\n>\n> The log family never compares things, but can show a patch, i.e. the\n> difference to the ancestor(s).\n\n(That's why I put `git diff' into the mix...)\n\nAnyway -- thanks for the overview. So IIUC, `rev-list' and `log' are\ndifferent in that the second can also format diffs -- ?\n\n\n>> Also related, it looks like `--abbrev-commit' has no effect on `git\n>> rev-list', but does on `git log', even through it's documented in the\n>> former's man page. So it looks like either there are more\n>> (undocumented?) differences, or maybe that's also a bug?\n>\n> I consider this a bug. In fact, it has an effect, but not a visible one.\n> You would have to use --abbrev=7 or such.\n>\n> A patch is upcoming.\n\nThanks.\n\nAnd one more question -- is there some %-escape that shows the whole\ncontents? Something like \"%(contents)\" in `for-each-ref'? (Which has\na different set of escapes...)\n\n-- \n ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:\n http://barzilay.org/ Maze is Life!\n"},{"id":"137570","messageId":"4BA7A75A.6060909@lsrfire.ath.cx","threadId":"23138","inReplyTo":"m3iq8opp8u.fsf@winooski.ccs.neu.edu","subject":"Re: git rev-list formatting","fromName":"René Scharfe","fromEmail":"rene.scharfe@lsrfire.ath.cx","sentAt":"2010-03-22T17:22:34Z","receivedAt":"2010-03-22T17:22:34Z","isPatch":false,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"Am 22.03.2010 12:30, schrieb Eli Barzilay:\n> Possible bug -- IIUC, this:\n> \n> git rev-list --pretty=\"%w(40,2,2)%b\" $rev\n> \n> should show all bodies wrapped as specified, but with 1.7.0.3 I see\n> only the first one wrapped, and the rest don't show up. In one of my\n> attempts to sort this, I saw all bodies, but all bodies after the\n> first were not wrapped as specified.\n\nI can't reproduce this when running this command against git's own repo.\n Or perhaps I just fail to see it. Is the one you're trying this on\npublic? Does it work as expected with some other version of git?\n\nThanks,\nRené\n"},{"id":"137602","messageId":"m31vfbpzol.fsf@winooski.ccs.neu.edu","threadId":"23138","inReplyTo":"4BA7A75A.6060909@lsrfire.ath.cx","subject":"Re: git rev-list formatting","fromName":"Eli Barzilay","fromEmail":"eli@barzilay.org","sentAt":"2010-03-23T01:57:46Z","receivedAt":"2010-03-23T01:57:46Z","isPatch":false,"sender":{"key":"eli@barzilay.org","avatar":"https://avatars.githubusercontent.com/u/185905?v=4"},"body":"René Scharfe writes:\n\n> Am 22.03.2010 12:30, schrieb Eli Barzilay:\n>> Possible bug -- IIUC, this:\n>> \n>> git rev-list --pretty=\"%w(40,2,2)%b\" $rev\n>> \n>> should show all bodies wrapped as specified, but with 1.7.0.3 I see\n>> only the first one wrapped, and the rest don't show up. In one of my\n>> attempts to sort this, I saw all bodies, but all bodies after the\n>> first were not wrapped as specified.\n>\n> I can't reproduce this when running this command against git's own\n> repo. Or perhaps I just fail to see it. Is the one you're trying\n> this on public? Does it work as expected with some other version of\n> git?\n\nSorry, I've lost track of all the different things I tried, but here's\nsomething that I can reproduce reliably now, which seems to be a\nsimilar problem (or at least nothing in the man page explain why it\nwould do what it does). If this is helpful, I'll tar up the\nrepository and put it up somewhere. This is all running in the repo\n-- and it case it matters, it's a bare repo, created with 1.7.0.\n\n $ git rev-list --pretty=\"%b\" foo\n\nshows one \"commit \" line, then the body, and then the rest of\nthe commits (13 of them) with no body at all (just the \"commit \"\nlines).\n\n $ git rev-list --pretty=\"%b\" 267d60518\n\nSame output -- 267d60518 is the commit that `foo' points to.\n\n $ git rev-list --pretty=\"%b\" 84482\n\nThis is for a commit that is somewhere in the middle of these commits,\nthe output has *only* \"commit \" lines -- no body shown.\n\n $ git rev-list --pretty 84482\n\nThis one works fine, showing all of the commits and their log\nmessages.\n\n-- \n ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:\n http://barzilay.org/ Maze is Life!\n"},{"id":"137623","messageId":"4BA89D88.7080803@drmicha.warpmail.net","threadId":"23138","inReplyTo":"m31vfbpzol.fsf@winooski.ccs.neu.edu","subject":"Re: git rev-list formatting","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2010-03-23T10:52:56Z","receivedAt":"2010-03-23T10:52:56Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Eli Barzilay venit, vidit, dixit 23.03.2010 02:57:\n> René Scharfe writes:\n> \n>> Am 22.03.2010 12:30, schrieb Eli Barzilay:\n>>> Possible bug -- IIUC, this:\n>>>\n>>> git rev-list --pretty=\"%w(40,2,2)%b\" $rev\n>>>\n>>> should show all bodies wrapped as specified, but with 1.7.0.3 I see\n>>> only the first one wrapped, and the rest don't show up. In one of my\n>>> attempts to sort this, I saw all bodies, but all bodies after the\n>>> first were not wrapped as specified.\n>>\n>> I can't reproduce this when running this command against git's own\n>> repo. Or perhaps I just fail to see it. Is the one you're trying\n>> this on public? Does it work as expected with some other version of\n>> git?\n> \n> Sorry, I've lost track of all the different things I tried, but here's\n> something that I can reproduce reliably now, which seems to be a\n> similar problem (or at least nothing in the man page explain why it\n> would do what it does). If this is helpful, I'll tar up the\n> repository and put it up somewhere. This is all running in the repo\n> -- and it case it matters, it's a bare repo, created with 1.7.0.\n\nI'd say that certainly matters (can't reproduce this one on non-bare\neither).\n\nWhen you say \"in the repo\", do you mean that you're current directory is\nwithin yourbarerepo.git? Do you have GIT_DIR set explicitly?\n\n> $ git rev-list --pretty=\"%b\" foo\n> \n> shows one \"commit \" line, then the body, and then the rest of\n> the commits (13 of them) with no body at all (just the \"commit \"\n> lines).\n[snip]\n\nMichael\n"},{"id":"137625","messageId":"m3ocifnvpd.fsf@winooski.ccs.neu.edu","threadId":"23138","inReplyTo":"4BA89D88.7080803@drmicha.warpmail.net","subject":"Re: git rev-list formatting","fromName":"Eli Barzilay","fromEmail":"eli@barzilay.org","sentAt":"2010-03-23T11:06:38Z","receivedAt":"2010-03-23T11:06:38Z","isPatch":false,"sender":{"key":"eli@barzilay.org","avatar":"https://avatars.githubusercontent.com/u/185905?v=4"},"body":"Michael J Gruber writes:\n\n> Eli Barzilay venit, vidit, dixit 23.03.2010 02:57:\n>> René Scharfe writes:\n>> \n>>> Am 22.03.2010 12:30, schrieb Eli Barzilay:\n>>>> Possible bug -- IIUC, this:\n>>>>\n>>>> git rev-list --pretty=\"%w(40,2,2)%b\" $rev\n>>>>\n>>>> should show all bodies wrapped as specified, but with 1.7.0.3 I see\n>>>> only the first one wrapped, and the rest don't show up. In one of my\n>>>> attempts to sort this, I saw all bodies, but all bodies after the\n>>>> first were not wrapped as specified.\n>>>\n>>> I can't reproduce this when running this command against git's own\n>>> repo. Or perhaps I just fail to see it. Is the one you're trying\n>>> this on public? Does it work as expected with some other version of\n>>> git?\n>> \n>> Sorry, I've lost track of all the different things I tried, but here's\n>> something that I can reproduce reliably now, which seems to be a\n>> similar problem (or at least nothing in the man page explain why it\n>> would do what it does). If this is helpful, I'll tar up the\n>> repository and put it up somewhere. This is all running in the repo\n>> -- and it case it matters, it's a bare repo, created with 1.7.0.\n>\n> I'd say that certainly matters (can't reproduce this one on non-bare\n> either).\n>\n> When you say \"in the repo\", do you mean that you're current\n> directory is within yourbarerepo.git?\n\nYes.\n\n\n> Do you have GIT_DIR set explicitly?\n\nNo.\n\n\n> [...]\n\nI've made a copy of the repository at\n\n http://tmp.barzilay.org/testing.git.tgz\n\nwhich shows what I said when I run\n\n git rev-list --pretty=\"%b\" 267d60518\n git rev-list --pretty=\"%b\" 84482\n\n-- \n ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:\n http://barzilay.org/ Maze is Life!\n"},{"id":"137630","messageId":"20100323122603.GA2053@coredump.intra.peff.net","threadId":"23138","inReplyTo":"m3ocifnvpd.fsf@winooski.ccs.neu.edu","subject":"Re: git rev-list formatting","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-03-23T12:26:03Z","receivedAt":"2010-03-23T12:26:03Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Mar 23, 2010 at 07:06:38AM -0400, Eli Barzilay wrote:\n\n> > [...]\n> \n> I've made a copy of the repository at\n> \n> http://tmp.barzilay.org/testing.git.tgz\n> \n> which shows what I said when I run\n> \n> git rev-list --pretty=\"%b\" 267d60518\n> git rev-list --pretty=\"%b\" 84482\n\nThe problem is that most of those commits don't _have_ bodies. Remember\nthat \"%b\" is about everything in the commit message after the first\nfirst paragraph.\n\nNow one might argue that rev-list should still put in the extra newline\nseparator in this case. I haven't been paying attention, but hasn't that\nbeen discussed in another thread recently?\n\n-Peff\n"},{"id":"137631","messageId":"40aa078e1003230540o40f551b2re8fbf1e70ae9ddbe@mail.gmail.com","threadId":"23138","inReplyTo":"20100323122603.GA2053@coredump.intra.peff.net","subject":"Re: git rev-list formatting","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@googlemail.com","sentAt":"2010-03-23T12:40:50Z","receivedAt":"2010-03-23T12:40:50Z","isPatch":false,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"On Tue, Mar 23, 2010 at 1:26 PM, Jeff King wrote:\n> On Tue, Mar 23, 2010 at 07:06:38AM -0400, Eli Barzilay wrote:\n>\n>> > [...]\n>>\n>> I've made a copy of the repository at\n>>\n>>   http://tmp.barzilay.org/testing.git.tgz\n>>\n>> which shows what I said when I run\n>>\n>>   git rev-list --pretty=\"%b\" 267d60518\n>>   git rev-list --pretty=\"%b\" 84482\n>\n> The problem is that most of those commits don't _have_ bodies. Remember\n> that \"%b\" is about everything in the commit message after the first\n> first paragraph.\n>\n> Now one might argue that rev-list should still put in the extra newline\n> separator in this case. I haven't been paying attention, but hasn't that\n> been discussed in another thread recently?\n>\n\nIf you're thinking of the stuff I've been working on, that's about\nmultiple commits ending up at the same line with --pretty=oneline, and\nnot _really_ about unconditionally adding that new-line. But it is\nclosely related, and it looks like it's the same code that is\nresponsible for the current behavior. Commit 55246aa is what made then\nnew-line conditional in the first place.\n\n-- \nErik \"kusma\" Faye-Lund\n"},{"id":"137632","messageId":"m3fx3rnqhz.fsf@winooski.ccs.neu.edu","threadId":"23138","inReplyTo":"20100323122603.GA2053@coredump.intra.peff.net","subject":"Re: git rev-list formatting","fromName":"Eli Barzilay","fromEmail":"eli@barzilay.org","sentAt":"2010-03-23T12:59:04Z","receivedAt":"2010-03-23T12:59:04Z","isPatch":false,"sender":{"key":"eli@barzilay.org","avatar":"https://avatars.githubusercontent.com/u/185905?v=4"},"body":"Jeff King writes:\n\n> On Tue, Mar 23, 2010 at 07:06:38AM -0400, Eli Barzilay wrote:\n>\n>> > [...]\n>> \n>> I've made a copy of the repository at\n>> \n>> http://tmp.barzilay.org/testing.git.tgz\n>> \n>> which shows what I said when I run\n>> \n>> git rev-list --pretty=\"%b\" 267d60518\n>> git rev-list --pretty=\"%b\" 84482\n>\n> The problem is that most of those commits don't _have_ bodies.\n> Remember that \"%b\" is about everything in the commit message after\n> the first first paragraph.\n\n*Ugh*... Yes, I've seen that a lot, yet somehow I managed to\ncompletely miss it. Sorry about the noise.\n\n\n> Now one might argue that rev-list should still put in the extra\n> newline separator in this case. I haven't been paying attention, but\n> hasn't that been discussed in another thread recently?\n\n(That might have made it more confusing, but I should still have\nguessed what's wrong...)\n\n-- \n ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:\n http://barzilay.org/ Maze is Life!\n"},{"id":"137885","messageId":"7vk4sylvzj.fsf@alter.siamese.dyndns.org","threadId":"23138","inReplyTo":"b1b0f22cf3dc6d67f6094e761a1b7402b1471e97.1269264868.git.git@drmicha.warpmail.net","subject":"Re: [PATCH] rev-list: heed --abbrev-commit option","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-03-26T19:32:32Z","receivedAt":"2010-03-26T19:32:32Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael J Gruber writes:\n\n> Currently, rev-list has a default of \"0\" for abbrev which means that\n> switching on abbreviations with --abbrev-commit has no visible effect,\n> even though the option is documented.\n\nHmm, I actually think this was deliberate. rev-list is designed to be a\nlow level machinery for getting full object names, and in that context,\nsetting the default abbreviation length to \"don't abbreviate\" gave us some\nsafety, with additional safety of requiring a separate --abbrev-commit\noption to affect the main \"show the commit object names\" codepath (the\nlatter of which would not likely to change). The caller sets explicitly\nhow long an output it wants (see git-rebase--interactive for an example).\n\nHaving said that, I don't think this would break existing scripts, so\nlet's queue it and see what happens.\n"},{"id":"137946","messageId":"4BAE0874.6090603@drmicha.warpmail.net","threadId":"23138","inReplyTo":"7vk4sylvzj.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] rev-list: heed --abbrev-commit option","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2010-03-27T13:30:28Z","receivedAt":"2010-03-27T13:30:28Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Junio C Hamano venit, vidit, dixit 26.03.2010 20:32:\n> Michael J Gruber writes:\n> \n>> Currently, rev-list has a default of \"0\" for abbrev which means that\n>> switching on abbreviations with --abbrev-commit has no visible effect,\n>> even though the option is documented.\n> \n> Hmm, I actually think this was deliberate. rev-list is designed to be a\n> low level machinery for getting full object names, and in that context,\n> setting the default abbreviation length to \"don't abbreviate\" gave us some\n> safety, with additional safety of requiring a separate --abbrev-commit\n> option to affect the main \"show the commit object names\" codepath (the\n> latter of which would not likely to change). The caller sets explicitly\n> how long an output it wants (see git-rebase--interactive for an example).\n\nMy thinking was that unless --abbrev-commit is specified, nothing is\nabbreviated, so that one has reproducible (plumbing) behaviour.\n\nI learned that --abbrev= implies --abbrev-commit, but again, this means\nexplicitly requiring non-plumbing behavior.\n\n> \n> Having said that, I don't think this would break existing scripts, so\n> let's queue it and see what happens.\n\nOK!\nMichael\n"}]}