blog.rss

   1 <?xml version="1.0" encoding="utf-8"?>
   2 <rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
   3 <channel>
   4 <title>Dscho's blog</title>
   5 <link>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html</link>
   6 <atom:link href="http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=blog.rss" rel="self" type="application/rss+xml"/>
   7 <description>A few stories told by Dscho</description>
   8 <lastBuildDate>Thu, 29 Jan 2009 02:44:27 +0100</lastBuildDate>
   9 <language>en-us</language>
  10 <item>
  11 <title>Interactive stash</title>
  12 <link>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1233193467</link>
  13 <guid>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1233193467</guid>
  14 <pubDate>Thu, 29 Jan 2009 02:44:27 +0100</pubDate>
  15 <description><![CDATA[Interactive stash
  16 </p><p>
  17 There is an easy way to split a patch:
  18 </p><p>
  19 <table
  20                                 border=1 bgcolor=white>
  21                         <tr><td bgcolor=lightblue colspan=3>
  22                                 <pre>                                                                                </pre>
  23                         </td></tr>
  24                         <tr><td>
  25                                 <table cellspacing=5 border=0
  26                                          style="color:black;">
  27                                 <tr><td>
  28                                         <pre>
  29 $ git reset HEAD^
  30 $ git add -i
  31 $ git commit
  32 $ git diff -R HEAD@{1} | git apply --index
  33 $ git commit
  34 </pre>
  35                                 </td></tr>
  36                                 </table>
  37                         </td></tr>
  38                         </table>
  39 </p><p>
  40 but it misses out on the fact that the first of both commits does not
  41 reflect the state of the working directory at any time.
  42 </p><p>
  43 So I think something like an interactive <i>stash</i> is needed.  A method
  44 to specify what you want to keep in the working directory, the rest should
  45 be stashed.  The idea would be something like this:
  46 </p><p>
  47 <ol>
  48 <li>Add the desired changes into a temporary index.
  49 <li>Put the rest of the changes in another temporary index.
  50 <li>Stash the latter index.
  51 <li>Synchronize the working directory with the first index.
  52 <li>Clean up temporary indices.
  53 </ol>
  54 </p><p>
  55 Or in code:
  56 </p><p>
  57 <table
  58                                 border=1 bgcolor=white>
  59                         <tr><td bgcolor=lightblue colspan=3>
  60                                 <pre>                                                                                </pre>
  61                         </td></tr>
  62                         <tr><td>
  63                                 <table cellspacing=5 border=0
  64                                          style="color:black;">
  65                                 <tr><td>
  66                                         <pre>
  67 $ cp .git/index .git/interactive-stash-1
  68 $ GIT_INDEX_FILE=.git/interactive-stash-1 git add -i
  69 $ cp .git/index .git/interactive-stash-2
  70 $ GIT_INDEX_FILE=.git/interactive-stash-1 git diff -R |
  71         (GIT_INDEX_FILE=.git/interactive-stash-2 git apply--index)
  72 $ tree=$(GIT_INDEX_FILE=.git/index git write-tree)
  73 $ commit=$(echo Current index | git commit-tree $tree -p HEAD)
  74 $ tree=$(GIT_INDEX_FILE=.git/interactive-stash-2 git write-tree)
  75 $ commit=$(echo Edited out | git commit-tree $tree -p HEAD -p $commit)
  76 $ git update-ref refs/stash $commit
  77 $ GIT_INDEX_FILE=.git/interactive-stash-1 git checkout-index -a -f
  78 $ rm .git/interactive-stash-1 .git/interactive-stash-2
  79 </pre>
  80                                 </td></tr>
  81                                 </table>
  82                         </td></tr>
  83                         </table>
  84 </p><p>
  85 This should probably go into <i>git-stash.sh</i>, maybe even with a switch
  86 to start git-gui to do the interactive adding instead of git-add.]]></description>
  87 </item>
  88 <item>
  89 <title>Splitting topic branches</title>
  90 <link>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1233154567</link>
  91 <guid>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1233154567</guid>
  92 <pubDate>Wed, 28 Jan 2009 15:56:07 +0100</pubDate>
  93 <description><![CDATA[Splitting topic branches
  94 </p><p>
  95 One might be put off easily by the overarching use of buzzwords in the
  96 description of how <i>Darcs</i> works.  I, for one, do not expect an intelligent
  97 author when I read <i>Theory of patches</i> and <i>based on quantum physics</i>.
  98 </p><p>
  99 The true story, however, is much simpler, and is actually not that dumb:
 100 Let's call two commits "conflicting" when they contain at least one
 101 overlapping change.
 102 </p><p>
 103 The idea is now: Given a list of commits (not a set, as the order is important),
 104 to sort them into smaller lists such that conflicting commits are in the
 105 sublists ("topic branches") and the sublists are minimal, i.e. no two
 106 non-conflicting commits are in the same sublist.
 107 </p><p>
 108 The idea has flaws, of course, as you can have a patch changing the code,
 109 and another changing the documentation, but splitting a list of commits
 110 in that way is a first step to sort out my <i>my-next</i> mess, where I have
 111 a linear perl of not-necessarily-dependent commits.
 112 </p><p>
 113 And actually, my whole rebase revamp aimed at the clean-up for my own
 114 <i>my-next</i> branch, so I am currently writing a script that can be used
 115 as a GIT_EDITOR for git-rebase which implements the Darcs algorithm.  Kind of:
 116 the result is not implicit, but explicit and can be fixed up later.]]></description>
 117 </item>
 118 <item>
 119 <title>Showing off that you're an Alpine user ... priceless!</title>
 120 <link>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1233102919</link>
 121 <guid>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1233102919</guid>
 122 <pubDate>Wed, 28 Jan 2009 01:35:19 +0100</pubDate>
 123 <description><![CDATA[Showing off that you're an Alpine user ... priceless!
 124 </p><p>
 125 So I was in a hurry to send the patches, and sent all the patches as replies
 126 to the cover-letter, and therefore typed in <i>rnyn</i> all the time, which is the
 127 mantra I need to say to Alpine for <i>Reply</i>, ... include quoted message?
 128 <i>No</i>, ... reply to all recipients? <i>Yes</i>, ... use first role?
 129 <i>No, use default role</i>.
 130 </p><p>
 131 That was pretty embarassing, as it shows everybody that I still do not trust
 132 <i>send-email</i>, and rather paste every single patch by hand.  Which is rather
 133 annoying.
 134 </p><p>
 135 So I started using format-patch today, to output directly to Alpine's
 136 <i>postponed-msgs</i> folder, so that I can do some touchups in the mailer
 137 before sending the patch series on its way.
 138 </p><p>
 139 However, when running format-patch with <i>--thread</i>, it generates Message-ID
 140 strings that Alpine does not like, and therefore replaces.
 141 </p><p>
 142 Oh, well, I'll probably just investigate how the Message-IDs are supposed to
 143 look, and then use sed to rewrite the generated ones by Alpine-friendly ones
 144 during the redirection to <i>postponed-msgs</i>.
 145 </p><p>
 146 But I alread realized that doing it that way is dramatically faster than the
 147 workflow I had before.
 148 </p><p>
 149 And safer: no more <i>rnyn</i>.]]></description>
 150 </item>
 151 <item>
 152 <title>Progress with the interactive rebase preserving merges</title>
 153 <link>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1233101919</link>
 154 <guid>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1233101919</guid>
 155 <pubDate>Wed, 28 Jan 2009 01:18:39 +0100</pubDate>
 156 <description><![CDATA[Progress with the interactive rebase preserving merges
 157 </p><p>
 158 I thought about the "dropped" commits a bit more, after all, and it is
 159 probably a good thing to substitute them by their parent, as Stephen did it.
 160 </p><p>
 161 Imagine that you have merged a branch with two commits.  One is in upstream,
 162 and you want to rebase (preserving merges) onto upstream.  Then you still
 163 want to merge the single commit.
 164 </p><p>
 165 Even better, if there is no commit left, the <i>$REWRITTEN</i> mechanism will
 166 substitute the commit onto which we are rebasing, so a merge will just
 167 result in a fast-forward!
 168 </p><p>
 169 Oh, another thing: merge commits should not have a patch id, as they have
 170 <u>multiple</u> patches.  However, I borked the code long time ago (9c6efa36)
 171 and merges get the patch-id of their diff to the first parent.  Which is
 172 probably wrong.  So I guess I'll have to fix that with my rebase revamp.
 173 </p><p>
 174 So what about a root commit?  If that was dropped, we will just substitute
 175 it with the commit onto which we rebase (as a root commit did not really
 176 have a parent, but will get the onto-commit as new parent)..
 177 </p><p>
 178 Now that I finally realized that t3410 is so strange because of a bug <u>I</u>
 179 introduced, I can finally go about fixing it.]]></description>
 180 </item>
 181 <item>
 182 <title>Another midnight riddle?</title>
 183 <link>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1233099894</link>
 184 <guid>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1233099894</guid>
 185 <pubDate>Wed, 28 Jan 2009 00:44:54 +0100</pubDate>
 186 <description><![CDATA[Another midnight riddle?
 187 </p><p>
 188 Okay, here's another riddle: what is the next line?
 189 </p><p>
 190 <pre>
 191        1
 192       1 1
 193       2 1
 194     1 1 1 2
 195     3 1 1 2
 196   2 1 1 2 1 3
 197 ...
 198 </pre>
 199 </p><p>
 200 And when does the line get wider than 10 digits?]]></description>
 201 </item>
 202 <item>
 203 <title>Fun with calculus after midnight</title>
 204 <link>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1233022809</link>
 205 <guid>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1233022809</guid>
 206 <pubDate>Tue, 27 Jan 2009 03:20:09 +0100</pubDate>
 207 <description><![CDATA[Fun with calculus after midnight
 208 </p><p>
 209 Problem: what is the shortest way of defining a variable consisting of <i>N</i>
 210 spaces?  I.e. for <i>N=80</i> the result will look something like
 211 </p><p>
 212 <table
 213                                 border=1 bgcolor=white>
 214                         <tr><td bgcolor=lightblue colspan=3>
 215                                 <pre>                                                                                </pre>
 216                         </td></tr>
 217                         <tr><td>
 218                                 <table cellspacing=5 border=0
 219                                          style="color:black;">
 220                                 <tr><td>
 221                                         <pre>
 222 s='    '
 223 s="$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s"
 224 </pre>
 225                                 </td></tr>
 226                                 </table>
 227                         </td></tr>
 228                         </table>
 229 </p><p>
 230 Let's see.  Let the minimal number of characters needed be <i>A(N)</i>.  For
 231 simplicity, let's say that we only use one variable.  Then, certainly, <i>A(N)</i>
 232 cannot be larger than <i>5+N</i>, as we could define a variable using 1 character
 233 for the name, 1 for the equal sign, 2 for the quotes, and one for the semicolon
 234 or newline character (whichever).
 235 </p><p>
 236 Now, let's assume <i>N</i> is a product <i>K*L</i>.  Then certainly, <i>A(N)</i> cannot
 237 be larger than <i>A(K)+5+2*L</i>, as we could first define a variable that has
 238 exactly <i>K</i> spaces and then use that to define the end result (in the example
 239 above, <i>K=5</i> and <i>L=20</i>).
 240 </p><p>
 241 So, for which <i>N=K*L</i> is it better to use two definitions instead of one?
 242 </p><p>
 243 Simple calculus says that <i>5+K*L>5+K+5+2*L</i> must hold true, or (after some
 244 scribbling): <i>L>1+7/(K-2)</i>. Which means that it makes no sense to define
 245 a variable with 1 or 2 spaces first, which is kinda obvious (writing '$s'
 246 alone would use two characters, so we could write the spaces right away).
 247 </p><p>
 248 But what for the other values?  For <i>K=3</i>, <i>L</i> must be at least 9 to make
 249 sense (in other words, <i>N</i> must be at least 27).  For <i>K=4</i>, <i>L</i> needs
 250 to be greater or equal to 5 (<i>N>=20</i>), the next pairs are <i>(5,4)</i>,
 251 <i>(6,3)</i>, <i>(7,3)</i>, <i>(8,3)</i>, <i>(9,3)</i> and starting with <i>K=10</i>, any
 252 <i>L>1</i> makes sense.
 253 </p><p>
 254 The second definition can also contain spaces at the end, however, so for any
 255 <i>N=K*L+M</i>, <i>A(N)</i> cannot be larger than <i>A(K)+5+2*L+M</i>.
 256 </p><p>
 257 Not surprisingly, this leads to exactly the same <i>L>1+7/(K-2)</i> (as we can
 258 append the <i>M</i> spaces in the last definition, no matter if we use 1 or
 259 2 definitions).
 260 </p><p>
 261 However, that means that as soon as <i>N>=18</i>, we should use two definitions,
 262 prior to that, it makes no sense.
 263 </p><p>
 264 So for <i>N<18</i>, <i>A(N)=5+N</i>.
 265 </p><p>
 266 But what <i>K</i> should one choose, i.e. how many spaces in the first definition?
 267 In other words, what is <i>A(N)</i> given that we use two definitions?
 268 </p><p>
 269 That will have to wait for another midnight.  Just a teaser: <i>A(80)=36</i>.  Oh,
 270 and with 80 characters, you can define a string of 9900 spaces...]]></description>
 271 </item>
 272 <item>
 273 <title>Valgrind takes a loooong time</title>
 274 <link>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1232997290</link>
 275 <guid>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1232997290</guid>
 276 <pubDate>Mon, 26 Jan 2009 20:14:50 +0100</pubDate>
 277 <description><![CDATA[Valgrind takes a loooong time
 278 </p><p>
 279 Yesterday, I started a run on a fast machine, and it took roughly 5.5
 280 hours by the machine's clock.
 281 </p><p>
 282 And of course, I redirected stdout only... *sigh*
 283 </p><p>
 284 Which triggered a Google search how to force redirection of all the output
 285 in the test scripts to a file and the terminal at the same time.
 286 </p><p>
 287 It seems as if that is not easily done.  I tried
 288 <center><table
 289                                 border=1 bgcolor=white>
 290                         <tr><td bgcolor=lightblue colspan=3>
 291                                 <pre>                                                                                </pre>
 292                         </td></tr>
 293                         <tr><td>
 294                                 <table cellspacing=5 border=0
 295                                          style="color:black;">
 296                                 <tr><td>
 297                                         <pre>
 298 exec >(tee out) 2>&1
 299 </pre>
 300                                 </td></tr>
 301                                 </table>
 302                         </td></tr>
 303                         </table></center>
 304 </p><p>
 305 but that did not work: it mumbled something about invalid file handles or some
 306 such.
 307 </p><p>
 308 The only solution I found was:
 309 <center><table
 310                                 border=1 bgcolor=white>
 311                         <tr><td bgcolor=lightblue colspan=3>
 312                                 <pre>                                                                                </pre>
 313                         </td></tr>
 314                         <tr><td>
 315                                 <table cellspacing=5 border=0
 316                                          style="color:black;">
 317                                 <tr><td>
 318                                         <pre>
 319 mkpipe pipe
 320 tee out < pipe &
 321 exec > pipe 2>&1
 322 </pre>
 323                                 </td></tr>
 324                                 </table>
 325                         </td></tr>
 326                         </table></center>
 327 </p><p>
 328 That is a problem for parallel execution, though, so I am still looking for a
 329 better way to do it.
 330 </p><p>
 331 Once I have the output, it is relatively easy to analyze it, as I already
 332 made a script which disects the output into valgrind output and the test
 333 case it came from, then groups by common valgrind output and shows the
 334 result to the user.]]></description>
 335 </item>
 336 <item>
 337 <title>A day full of rebase... and a little valgrind</title>
 338 <link>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1232927812</link>
 339 <guid>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1232927812</guid>
 340 <pubDate>Mon, 26 Jan 2009 00:56:52 +0100</pubDate>
 341 <description><![CDATA[A day full of rebase... and a little valgrind
 342 </p><p>
 343 I think that I am progressing nicely with my rebase -p work, so much so
 344 that I will soon be able to use it myself to work on topic branches <u>and</u>
 345 rebase all the time without much hassle.
 346 </p><p>
 347 In other words, I would like to be able to rebase all my topic branches
 348 to Junio's <i>next</i> branch whenever that has new commits.  With a single
 349 rebase.
 350 </p><p>
 351 And finally, I got the idea of the thing Stephen implemented for dropped
 352 commits; however, I am quite sure I do not like it.
 353 </p><p>
 354 So what are "dropped" commits?
 355 </p><p>
 356 When you rebase, chances are that the upstream already has applied at
 357 least some of your patches.  So we filter those out with <i>--cherry-pick</i>.
 358 Stephen calls those "dropped" commits.
 359 </p><p>
 360 Then he goes on to reinvent the "$REWRITTEN" system: a directory containing
 361 the mappings of old commit names to new commit names.  That is easily fixed.
 362 </p><p>
 363 But worse, he substitutes the dropped commits with their <u>parents</u>, instead
 364 of substituting them with the corresponding commits in upstream.
 365 </p><p>
 366 I guess this will be a medium-sized fight on the mailing list, depending
 367 how much energy Stephen wants to put in to defend his strategy.
 368 </p><p>
 369 Anyway, I finally got to a point where only three of the tests are failing,
 370 t3404, t3410 and t3412.  Somewhat disappointing is t3404, as its name pretends
 371 not to exercize -p at all.  Oh well, I guess I'll see what is broken tomorrow.
 372 </p><p>
 373 Another part of the day was dedicated to the Valgrind patch series, which
 374 should give us yet another level of code quality.
 375 </p><p>
 376 After having confused myself with several diverging/obsolete branches, I did
 377 indeed finally manage to send that patch series off.  Woohoo.]]></description>
 378 </item>
 379 <item>
 380 <title>Regular diff with word coloring (as opposed to word diff)</title>
 381 <link>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1232888842</link>
 382 <guid>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1232888842</guid>
 383 <pubDate>Sun, 25 Jan 2009 14:07:22 +0100</pubDate>
 384 <description><![CDATA[Regular diff with word coloring (as opposed to word diff)
 385 </p><p>
 386 You know, if I were a bit faster with everything I do, I could do so much more!
 387 </p><p>
 388 For example, Junio's idea that you could keep showing a regular diff, only
 389 coloring the words that have been removed/deleted.
 390 </p><p>
 391 Just imagine looking at the diff of a long line in LaTeX source code.  It
 392 should be much nicer to the eye to see the complete removed/added sentences
 393 instead of one sentence with colored words in between, disrupting your read
 394 flow.
 395 </p><p>
 396 Compare these two versions:
 397 </p><p>
 398 Regular diff with colored words:
 399 <blockquote><tt>
 400 -This sentence has a <font color=red>tyop</font> in it.<br>
 401 +This sentence has a <font color=green>typo</font> in it.<br>
 402 </tt></blockquote>
 403 </p><p>
 404 Word diff:
 405 <blockquote><tt>
 406 This sentence has a <font color=red>tyop</font><font color=green>typo</font> in it.<br>
 407 </tt></blockquote>
 408 </p><p>
 409 And it should not be hard to do at all!
 410 </p><p>
 411 In <i>diff_words_show()</i>, we basically get the minus lines as
 412 <i>diff_words->minus</i> and the plus lines as <i>diff_words->plus</i>.  The
 413 function then prepares the word lists and calls the xdiff engine to do all the
 414 hard work, analyzing the result from xdiff and printing the lines in
 415 <i>fn_out_diff_words_aux()</i>.
 416 </p><p>
 417 So all that would have to be changed would be to <u>record</u> the positions
 418 of the removed/added words instead of outputting them, and at the end printing
 419 the minus/plus buffers using the recorded information to color the words.
 420 </p><p>
 421 This would involve
 422 </p><p>
 423 <ul>
 424 <li>adding two new members holding the offsets in the <i>diff_words</i>
 425 struct,
 426 <li>having a special handling for that mode in
 427 <i>fn_out_diff_words_aux()</i> that appends the offsets and
 428 returns,
 429 <li>adding a function <i>show_lines_with_colored_words()</i> that
 430 outputs a buffer with a given prefix ('-' or '+') and coloring the words at
 431 given offsets with a given color,
 432 <li>modify <i>diff_words_show()</i> to call that function for the "special
 433 case: only removal" and at the end of the function, and
 434 <li> disabling the <i>fwrite()</i> at the end of <i>diff_words_show()</i> for that
 435 mode.
 436 </ul>
 437 </p><p>
 438 Of course, the hardest part is to find a nice user interface for that.  Maybe
 439 <i>--colored-words</i>? &#x263a;]]></description>
 440 </item>
 441 <item>
 442 <title>Ideas for a major revamp of the --preserve-merges handling in git rebase</title>
 443 <link>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1232828715</link>
 444 <guid>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1232828715</guid>
 445 <pubDate>Sat, 24 Jan 2009 21:25:15 +0100</pubDate>
 446 <description><![CDATA[Ideas for a major revamp of the <i>--preserve-merges</i> handling in <i>git rebase</i>
 447 </p><p>
 448 As probably everybody agrees, the code to preserve merges is a big mess
 449 right now.
 450 </p><p>
 451 Worse, the whole concept of "pick <merge-sha1>" just does not fly well.
 452 </p><p>
 453 So I started a <u>major</u> cleanup, which happens to reduce the code very
 454 nicely so far.
 455 </p><p>
 456 It will take a few days to flesh out, I guess, but these are the major
 457 ideas of my work:
 458 </p><p>
 459 <b>pick $sha1</b><br>
 460 <blockquote>will only work on non-merges in the future.</blockquote>
 461 <b>merge $sha1 [$sha1...] was $sha1 Merge ...</b><br>
 462 <blockquote>will merge the given list of commits into the current HEAD, for
 463         the user's reference and to keep up-to-date what was rewritten,
 464         the original merge is shown after the keyword "was" (which is not
 465         a valid SHA-1, luckily).</blockquote>
 466 <b>goto $sha1</b><br>
 467 <blockquote>will reset the HEAD to the given commit.</blockquote>
 468 <b>$sha1'</b><br>
 469 <blockquote>for merge and goto, if a $sha1 ends in a single quote, the
 470         rewritten commit is substituted (if there is one).</blockquote>
 471 </p><p>
 472 Example:
 473 </p><p>
 474 <pre>
 475 A - B - - - E
 476   \       /
 477     C - D
 478 </pre>
 479 </p><p>
 480 could yield this TODO script:
 481 </p><p>
 482 <pre>
 483         pick A
 484         pick C
 485         pick D
 486         goto A'
 487         pick B
 488         merge D' was E
 489 </pre>
 490 </p><p>
 491 This should lead to a much more intuitive user experience.
 492 </p><p>
 493 I am very sorry if somebody actually scripted <i>rebase -i -p</i> (by setting
 494 GIT_EDITOR with a script), but I am very certain that this cleanup is
 495 absolutely necessary to make <i>rebase -i -p</i> useful.]]></description>
 496 </item>
 497 </channel>
 498 </rss>