index.html

   1 <html>
   2         <head>
   3                 <title>Dscho's Git log</title>
   4                 <meta http-equiv="Content-Type"
   5                         content="text/html; charset=UTF-8"/>
   6         </head>
   7         <body style="width:800px;background-image:url(dscho.git?a=blob_plain;hb=832be85c785c80202f17b87db7f063ae57ec2cac;f=paper.jpg);background-repeat:repeat-y;background-attachment:scroll;padding:0px;">
   8                 <div style="width:610px;margin-left:120px;margin-top:50px;align:left;vertical-align:top;">
   9                         <h1>Dscho's Git log</h1>
  10                         <div style="position:absolute;top:50px;left:810px;width=400px">
  11                         <table width=400px bgcolor=#e0e0e0 border=1>
  12                         <tr><th>Table of contents:</th></tr>
  13                         <tr><td>
  14                         <p><ul>
  15                         <li><a href=#1235092615>20 Feb 2009 Code reviews</a>
  16                         <li><a href=#1234409395>12 Feb 2009 Interactive <i>rebase</i> just learnt a new command: <i>topic</i></a>
  17                         <li><a href=#1234320806>11 Feb 2009 Thunderbird, oh Thunderbird, you always make my small brain hurt</a>
  18                         <li><a href=#1234141489>09 Feb 2009 <i>format-patch --thread</i> and Alpine</a>
  19                         <li><a href=#1234140696>09 Feb 2009 <i>rebase</i> updates</a>
  20                         <li><a href=#1234040744>07 Feb 2009 The infamous <i>mark</i> command in the <i>rebase</i> command</a>
  21                         <li><a href=#1233707628>04 Feb 2009 New valgrind series</a>
  22                         <li><a href=#1233706294>04 Feb 2009 Problems with split-topic-branches.sh</a>
  23                         <li><a href=#1233277286>30 Jan 2009 More valgrind fun</a>
  24                         <li><a href=#1233193467>29 Jan 2009 Interactive stash</a>
  25                         </ul></p>
  26                         <a href=dscho.git?a=blob_plain;hb=5204f7b2812bc27ee97fe72131e35f198fc0b4c6;f=index.html>Older posts</a>
  27                         </td></tr></table>
  28                         <br>
  29                         <div style="text-align:right;">
  30                         <a href="dscho.git?a=blob_plain;hb=blog;f=blog.rss"
  31                            title="Subscribe to my RSS feed"
  32                            class="rss" rel="nofollow"
  33                            style="background-color:orange;text-decoration:none;color:white;font-family:sans-serif;">RSS</a>
  34                         </div>
  35                         <br>
  36                         <table width=400px bgcolor=#e0e0e0 border=1>
  37                         <tr><th>About this blog:</th></tr>
  38                         <tr><td>
  39                         <p>It is an active <a href=http://repo.or.cz/w/git/dscho.git?a=blob_plain;f=index.html;hb=5f002cab57a837125a8f901bcd1f3c1477bc3119>abuse</a> of <a href=http://repo.or.cz/>repo.or.cz</a>,
  40                         letting gitweb unpack the objects in the current tip of the branch <i>blog</i>,
  41                         including the images and the RSS feed.
  42                         </p><p>
  43                         Publishing means running a script that collects the posts, turns them into
  44                         HTML, makes sure all the images are checked in, and pushes the result.
  45                         </p><p>
  46                         This blog also serves to grace the world with Dscho's random thoughts on and
  47                         around Git.
  48                         </p>
  49                         </td></tr></table>
  50                         <br>
  51                         <table width=400px bgcolor=#e0e0e0 border=1>
  52                         <tr><th>Links:</th></tr>
  53                         <tr><td>
  54                         <ul>
  55                         <li> <a href=http://git-scm.com/>Git's homepage</a>
  56                         <li> <a href=http://gitster.livejournal.com/>Junio's blog</a>
  57                         <li> <a href=http://www.spearce.org/>Shawn's blog</a> seems to be sitting
  58                               idle ever since he started working for Google...
  59                         <li> <a href=http://torvalds-family.blogspot.com/>Linus' blog</a> does not
  60                               talk much about Git...
  61                         <li> Scott Chacon's <a href=http://whygitisbetterthanx.com/>Why Git is better
  62                              than X</a> site
  63                         <li> <a href=http://vilain.net/>The blog of mugwump</a>
  64                         <li> <a href=http://blogs.gnome.org/newren/>Elijah Newren</a> chose the
  65                               same path as Cogito, offering an alternative porcelain (an approach
  66                               that is doomed in my opinion)
  67                         <li> <a href=http://msysgit.googlecode.com/>The msysGit project</a>, a (mostly)
  68                               failed experiment to lure the many Windows developers out there to
  69                               contribute to Open Source for a change.
  70                         </ul>
  71                         </td></tr></table>
  72                         <br>
  73                         <table width=400px bgcolor=#e0e0e0 border=1>
  74                         <tr><th>Google Ads:</th></tr>
  75                         <tr><td>
  76                         <script type="text/javascript"><!--
  77                         google_ad_client = "pub-5106407705643819";
  78                         /* 300x250, created 1/22/09 */
  79                         google_ad_slot = "6468207338";
  80                         google_ad_width = 300;
  81                         google_ad_height = 250;
  82                         //-->
  83                         </script>
  84                         <script type="text/javascript"
  85                         src="http://pagead2.googlesyndication.com/pagead/show_ads.js">
  86                         </script>
  87                         </td></tr></table>
  88                         </div>
  89                         <h6>Friday, 20th of February, Anno Domini MMIX, at the hour of the Buffalo</h6>
  90                         <a name=1235092615>
  91                         <h2>Code reviews</h2>
  92
  93                         <p>
  94                         </p><p>
  95                         It has been said that reviewing patches is a most thankless job.  As I really
  96                         like the elegance of Git's source code, and care a lot about it, I did not
  97                         think that it was thankless, just a little bit tedious (especially when the
  98                         patch authors mistake criticism for personal attacks).
  99                         </p><p>
 100                         Usually, I am pretty good at ignoring insults as responses to my comments;
 101                         after all, I have a lot more enjoyable things to do than to spend time talking
 102                         to a guy who shows how wise he is when he thinks that I criticize him
 103                         <u>personally</u> when I just try to enhance his work, by offering a little bit of
 104                         my knowledge.
 105                         </p><p>
 106                         However, in the last days, three people really seemed to want to insult me,
 107                         to make me go away, to stop the fun I have with Git.
 108                         </p><p>
 109                         And they almost succeeded.
 110                         </p><p>
 111                         So I guess it is time to reassess my priorities, and maybe stop reviewing
 112                         Git patches altogether.
 113                         </p>
 114                         <h6>Thursday, 12th of February, Anno Domini MMIX, at the hour of the Tiger</h6>
 115                         <a name=1234409395>
 116                         <h2>Interactive <i>rebase</i> just learnt a new command: <i>topic</i></h2>
 117
 118                         <p>
 119                         </p><p>
 120                         Today I am pretty pleased with myself.  Two projects at my day job got a real
 121                         boost, and I implemented a shortcut that avoids the ugly 'bookmark' statement
 122                         in rebase scripts most of the time.
 123                         </p><p>
 124                         A typical rebase script, generated by <i>git rebase -i -p $COMMIT</i> will look
 125                         something like this:
 126                         </p><p>
 127                         <table
 128                                                         border=1 bgcolor=black>
 129                                                 <tr><td bgcolor=lightblue colspan=3>
 130                                 <pre>                                                                                </pre>
 131                         </td></tr>
 132                         <tr><td>
 133                                 <table cellspacing=5 border=0
 134                                          style="color:white;">
 135                                 <tr><td>
 136                                         <pre>
 137 pick 1234567 My first commit
 138 topic begin super-cool-feature
 139 pick 2345678 The super cool feature
 140 pick 3456789 Documentation for the super cool feature
 141 topic end super-cool-feature
 142 </pre>
 143                                                         </td></tr>
 144                                                         </table>
 145                                                 </td></tr>
 146                                                 </table>
 147                         </p><p>
 148                         The result will be a merge commit at the HEAD whose first parent is
 149                         "My first commit", whose second parent is "Documentation for the super
 150                         cool feature" and whose commit message is "Merge branch 'super-cool-feature'".
 151                         </p><p>
 152                         Side note: internally, <i>topic begin $NAME [at $COMMIT]</i> will be handled as if
 153                         you wrote <i>bookmark merge-parent-of-$NAME; goto $COMMIT</i>, and
 154                         <i>topic end $NAME [$MESSAGE]</i> will be handled as if you wrote
 155                         <i>bookmark $NAME; goto merge-parent-of-$NAME; merge parents $NAME [original $MARK Merge branch '$NAME']</i>.
 156                         </p><p>
 157                         Of course, being more concise, the 'topic' statement is not only nicer to the
 158                         eye, but also less error-prone.
 159                         </p><p>
 160                         And hopefully many people will agree with me that this rebase script is pretty
 161                         intuitive.
 162                         </p>
 163                         <h6>Wednesday, 11th of February, Anno Domini MMIX, at the hour of the Tiger</h6>
 164                         <a name=1234320806>
 165                         <h2>Thunderbird, oh Thunderbird, you always make my small brain hurt</h2>
 166
 167                         <p>
 168                         </p><p>
 169                         There was a lengthy discussion on the Git mailing list about using Thunderbird,
 170                         a not quite unpopular mailing program, to send inline patches.
 171                         </p><p>
 172                         It is really kind of sad that the Thunderbird developers do not see how
 173                         stubbornly they offend quite a number of people and scare them away from their
 174                         program.  After all, you should try to be liberal in what you accept and strict
 175                         in what you emit.  No, that does not mean that you should force others to
 176                         switch their mailers because you strictly adher to your philosophy in what you
 177                         emit, ignoring the rest of the world.
 178                         </p><p>
 179                         In any case, I am not affected (as long as I do not get mails from a poor soul
 180                         stuck with Thunderbird).
 181                         </p><p>
 182                         But I was a bit mean to that Thunderbird guy I dragged into the discussion, and
 183                         he seems really offended.
 184                         </p><p>
 185                         So I thought I'd give him a real reason to feel offended: I'll just do his work:
 186                         </p><p>
 187                         http://<a href=http://repo.or.cz>repo.or.cz</a>/w/UnFlowedThunderbird.git
 188                         </p><p>
 189                         It took my free time of two days, being not a Thunderbird developer myself.
 190                         Hopefully it works, and hopefully some people will feel really ashamed now.
 191                         </p>
 192                         <h6>Monday, 9th of February, Anno Domini MMIX, at the hour of the Buffalo</h6>
 193                         <a name=1234141489>
 194                         <h2><i>format-patch --thread</i> and Alpine</h2>
 195
 196                         <p>
 197                         </p><p>
 198                         I started recently to pipe the output of
 199                         <i>git format-patch --cover-letter --stdout ...</i> directly into the
 200                         <i>postponed-msgs</i> folder Alpine uses, instead of pasting files into the
 201                         mailer.
 202                         </p><p>
 203                         The idea is to pretend that I continue a postponed mail, but in reality I
 204                         never wrote it, <i>format-patch</i> did.
 205                         </p><p>
 206                         However, I had problems with the <i>--thread</i> option that is implied by
 207                         <i>--cover-letter</i>.  Alpine always generated new message IDs without adjusting
 208                         the <i>In-reply-to:</i> and <i>References:</i> headers of the other mails.
 209                         </p><p>
 210                         Now I found out that the reason is that the <i>Fcc:</i> headers were missing in
 211                         the mails, and Alpine generated them, making up new message IDs in the process.
 212                         </p><p>
 213                         Therefore I have an alias now which sets not only the <i>Fcc:</i> header, but also
 214                         the <i>To:</i> headers by rewriting the stream using <i>sed</i>.  This is slightly
 215                         ugly, but so is the handling of headers in <i>format-patch</i>: if you thought
 216                         you could specify arbitrary headers using the command line, you are mistaken:
 217                         you can do that only by editing the config.
 218                         </p><p>
 219                         While at it, I also noticed a bug whereby <i>--thread --in-reply-to=...</i> simply
 220                         forgets the <i>--thread</i>.  Maybe this week I will find time to address this bug.
 221                         </p>
 222                         <h6>Monday, 9th of February, Anno Domini MMIX, at the hour of the Buffalo</h6>
 223                         <a name=1234140696>
 224                         <h2><i>rebase</i> updates</h2>
 225
 226                         <p>
 227                         </p><p>
 228                         Phew.  The last few days, I was mainly chasing bugs I introduced due to being
 229                         too tired to work on the merge-preserving, interactive <i>rebase</i>.
 230                         </p><p>
 231                         But finally I have something I can start working with.  After my failed
 232                         experiment to use git-blame to split topic branches, I will sort the commits
 233                         in my <i>my-next</i> branch into topic branches manually.
 234                         </p><p>
 235                         Then I will add an option to <i>rebase -i -p</i> to rewrite refs which point to
 236                         rewritten commits, so that I can have branches <i>rebase-i-p</i>, <i>add-e</i>, etc
 237                         and all of them are automatically updated when I <i>rebase -i -p</i> the <i>my-next</i>
 238                         branch.
 239                         </p><p>
 240                         In the process, not only have I learnt the value of the <i>bookmark</i> command,
 241                         but made quite a few-much needed cleanups (which make
 242                         <i>git-rebase--interactive.sh</i> longer, but much more understandable).
 243                         </p><p>
 244                         Hopefully Stephan will pick the changes in the "rebase protocol" up, and then
 245                         we can have a sequencer with which I can start to make a graphical interactive
 246                         rebase using git-gui.  Or gitk.
 247                         </p><p>
 248                         Maybe.
 249                         </p>
 250                         <h6>Saturday, 7th of February, Anno Domini MMIX, at the hour of the Pig</h6>
 251                         <a name=1234040744>
 252                         <h2>The infamous <i>mark</i> command in the <i>rebase</i> command</h2>
 253
 254                         <p>
 255                         </p><p>
 256                         I realized today how easy it is to lose commits with the "merge preserving"
 257                         mode of the interactive rebase.  In my case, it was when I tried to move a
 258                         bunch of commits from the tip of my branch into a topic branch.
 259                         </p><p>
 260                         But after moving the commits, I forgot to update the parent of the merge
 261                         commit.  Possibly a mark command could have helped.  The very same command
 262                         I called a nightmare for usability.
 263                         </p><p>
 264                         So I was wrong.  Big news.  &#x263a;
 265                         </p><p>
 266                         However, I think that the syntax "mark :1" is something best left for
 267                         machine consumption, not for human beings.
 268                         </p><p>
 269                         But I have an idea: we could use some garbled commit subject, or in case of
 270                         merge parents, the merge subject as some human readable title of the mark.
 271                         </p><p>
 272                         The rebase script would then look something like this:
 273                         </p><p>
 274                         <table
 275                                                         border=1 bgcolor=black>
 276                                                 <tr><td bgcolor=lightblue colspan=3>
 277                                 <pre>                                                                                </pre>
 278                         </td></tr>
 279                         <tr><td>
 280                                 <table cellspacing=5 border=0
 281                                          style="color:white;">
 282                                 <tr><td>
 283                                         <pre>
 284 pick abcdefg Some ultra cool commit
 285 bookmark ultra-cool
 286 goto upstream
 287 pick hijklmn Some other cool commit
 288 merge parent ultra-cool Merge 'ultra-cool' into master
 289 </pre>
 290                                                         </td></tr>
 291                                                         </table>
 292                                                 </td></tr>
 293                                                 </table>
 294                         </p><p>
 295                         The good news is: I added code that refuses to finish a rebase when there
 296                         are commits that were rewritten, but not part of the new HEAD's ancestry.
 297                         </p>
 298                         <h6>Wednesday, 4th of February, Anno Domini MMIX, at the hour of the Buffalo</h6>
 299                         <a name=1233707628>
 300                         <h2>New valgrind series</h2>
 301
 302                         <p>
 303                         </p><p>
 304                         I spent quite some time cleaning up that patch series, and feel pretty
 305                         exhausted.
 306                         </p><p>
 307                         Granted, the new <i>git rebase -i -p</i> does its job without complaint so far
 308                         (so much so that I think I'll release a version of my <i>rebase</i> series
 309                         soonish), but it <u>is</u> a hassle when you have patches that you have a hard
 310                         time to decide upon the order/commit boundaries.
 311                         </p><p>
 312                         For example, I could imagine that the patch making the location of the
 313                         templates independent of the location of the Git binaries should come
 314                         <u>before</u> my patch series, and the valgrind specific part should then
 315                         be squashed into the first valgrind commit.
 316                         </p><p>
 317                         Also, it uses two features of valgrind 3.4.0:
 318                         </p><p>
 319                         <ul>
 320                         <li><i>...</i> in the suppression file, and
 321                         <li><i>--track-origins=yes</i>
 322                         </ul>
 323                         </p><p>
 324                         The latter is actually the reason I am pretty willing to keep the
 325                         requirement of that valgrind version, as it is really, really useful.
 326                         </p><p>
 327                         I guess we will see what happens to it.
 328                         </p>
 329                         <h6>Wednesday, 4th of February, Anno Domini MMIX, at the hour of the Buffalo</h6>
 330                         <a name=1233706294>
 331                         <h2>Problems with split-topic-branches.sh</h2>
 332
 333                         <p>
 334                         </p><p>
 335                         So my little script that should help me to split my topic branches does
 336                         not work properly.
 337                         </p><p>
 338                         First some background: the idea was to let <i>git blame</i> do the hard work
 339                         to find overlapping changes, i.e. changes that would conflict when
 340                         changing the order (or skipping the first change, on which the next builds).
 341                         </p><p>
 342                         The first problem with that approach: when lines are <u>removed</u> by one
 343                         commit, and the next commit touches the same location, <i>git blame</i> does
 344                         not find that the first commit is required by the second.
 345                         </p><p>
 346                         Therefore I introduced a really slow reverse thing which tries to find
 347                         those commits whose removals survived until the parent of a particular
 348                         commit, but not further.
 349                         </p><p>
 350                         However, it does not work properly.  Basically, only context sizes that
 351                         span the whole files lead to conflict-free topic branches so far.
 352                         </p><p>
 353                         As a consequence, I think I'll add an option --sprout to the revision
 354                         walker which will fake octopus merges (or a series of two-parent merges)
 355                         whenever it finds a perl of non-merge commits that are theoretically
 356                         independent, i.e. whose patches apply cleanly.
 357                         </p>
 358                         <h6>Friday, 30th of January, Anno Domini MMIX, at the hour of the Buffalo</h6>
 359                         <a name=1233277286>
 360                         <h2>More valgrind fun</h2>
 361
 362                         <p>
 363                         </p><p>
 364                         So I spent quite a number of hours on that funny zlib/valgrind issue.  The
 365                         thing is, zlib people claim that even if their code accesses uninitialized
 366                         memory, it does not produce erroneous data (by cutting out the results of the
 367                         uninitialized data, which is cheaper than checking for the end of the buffer
 368                         in an unaligned manner), so zlib will always be special for valgrind.
 369                         </p><p>
 370                         However, the bug I was chasing is funny, and different from said issue.  zlib
 371                         deflates an input buffer to an output buffer that is exactly 58 bytes long.
 372                         But valgrind claims that the 52nd of those bytes is uninitialized, and <u>only</u>
 373                         that one.
 374                         </p><p>
 375                         But it is not.  It must be 0x2c, otherwise zlib refuses to inflate the
 376                         buffer.
 377                         </p><p>
 378                         Now, I went into a debugging frenzy, and finally found out that zlib just
 379                         passes fine (with the default suppressions because of the "cute" way it
 380                         uses uninitialized memory), <u>except</u> when it is compiled with UNALIGNED_OK
 381                         defined.
 382                         </p><p>
 383                         Which Ubuntu does, of course.  Ubuntu, the biggest forker of all.
 384                         </p><p>
 385                         The bad part is that it sounds like a bug in valgrind, and I <u>could</u> imagine
 386                         that it is an issue of an optimized memcpy() that copies int by int, and
 387                         that valgrind misses out on the fact that a part of that int is actually
 388                         <u>not</u> uninitialized.
 389                         </p><p>
 390                         But my debugging session's results disagree with that.
 391                         </p><p>
 392                         With the help of Julian Seward, the original author of valgrind, I instrumented
 393                         zlib's source code so that valgrind checks earlier if the byte is initialized
 394                         or not, to find out where the reason of the issue lies.
 395                         </p><p>
 396                         The sad part is that when I added the instrumentation to both the <u>end</u> of
 397                         the while() loop in compress_block() in zlib's trees.c, and just <u>after</u> the
 398                         while() loop (whose condition is a plain <i>variable < variable</i> comparison,
 399                         nothing fancy, certainly not changing any memory), only the <u>latter</u> catches
 400                         a valgrind error.
 401                         </p><p>
 402                         And that is truly strange.
 403                         </p>
 404                         <h6>Thursday, 29th of January, Anno Domini MMIX, at the hour of the Buffalo</h6>
 405                         <a name=1233193467>
 406                         <h2>Interactive stash</h2>
 407
 408                         <p>
 409                         </p><p>
 410                         There is an easy way to split a patch:
 411                         </p><p>
 412                         <table
 413                                                         border=1 bgcolor=black>
 414                                                 <tr><td bgcolor=lightblue colspan=3>
 415                                 <pre>                                                                                </pre>
 416                         </td></tr>
 417                         <tr><td>
 418                                 <table cellspacing=5 border=0
 419                                          style="color:white;">
 420                                 <tr><td>
 421                                         <pre>
 422 $ git reset HEAD^
 423 $ git add -i
 424 $ git commit
 425 $ git diff -R HEAD@{1} | git apply --index
 426 $ git commit
 427 </pre>
 428                                                         </td></tr>
 429                                                         </table>
 430                                                 </td></tr>
 431                                                 </table>
 432                         </p><p>
 433                         but it misses out on the fact that the first of both commits does not
 434                         reflect the state of the working directory at any time.
 435                         </p><p>
 436                         So I think something like an interactive <i>stash</i> is needed.  A method
 437                         to specify what you want to keep in the working directory, the rest should
 438                         be stashed.  The idea would be something like this:
 439                         </p><p>
 440                         <ol>
 441                         <li>Add the desired changes into a temporary index.
 442                         <li>Put the rest of the changes in another temporary index.
 443                         <li>Stash the latter index.
 444                         <li>Synchronize the working directory with the first index.
 445                         <li>Clean up temporary indices.
 446                         </ol>
 447                         </p><p>
 448                         Or in code:
 449                         </p><p>
 450                         <table
 451                                                         border=1 bgcolor=black>
 452                                                 <tr><td bgcolor=lightblue colspan=3>
 453                                 <pre>                                                                                </pre>
 454                         </td></tr>
 455                         <tr><td>
 456                                 <table cellspacing=5 border=0
 457                                          style="color:white;">
 458                                 <tr><td>
 459                                         <pre>
 460 $ cp .git/index .git/interactive-stash-1
 461 $ GIT_INDEX_FILE=.git/interactive-stash-1 git add -i
 462 $ cp .git/index .git/interactive-stash-2
 463 $ GIT_INDEX_FILE=.git/interactive-stash-1 git diff -R |
 464         (GIT_INDEX_FILE=.git/interactive-stash-2 git apply--index)
 465 $ tree=$(GIT_INDEX_FILE=.git/index git write-tree)
 466 $ commit=$(echo Current index | git commit-tree $tree -p HEAD)
 467 $ tree=$(GIT_INDEX_FILE=.git/interactive-stash-2 git write-tree)
 468 $ commit=$(echo Edited out | git commit-tree $tree -p HEAD -p $commit)
 469 $ git update-ref refs/stash $commit
 470 $ GIT_INDEX_FILE=.git/interactive-stash-1 git checkout-index -a -f
 471 $ rm .git/interactive-stash-1 .git/interactive-stash-2
 472 </pre>
 473                                                         </td></tr>
 474                                                         </table>
 475                                                 </td></tr>
 476                                                 </table>
 477                         </p><p>
 478                         This should probably go into <i>git-stash.sh</i>, maybe even with a switch
 479                         to start git-gui to do the interactive adding instead of git-add.
 480                         </p>
 481                 </div>
 482         </body>
 483 </html>