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=#1234409395>12 Feb 2009 Interactive <i>rebase</i> just learnt a new command: <i>topic</i></a>
  16                         <li><a href=#1234320806>11 Feb 2009 Thunderbird, oh Thunderbird, you always make my small brain hurt</a>
  17                         <li><a href=#1234141489>09 Feb 2009 <i>format-patch --thread</i> and Alpine</a>
  18                         <li><a href=#1234140696>09 Feb 2009 <i>rebase</i> updates</a>
  19                         <li><a href=#1234040744>07 Feb 2009 The infamous <i>mark</i> command in the <i>rebase</i> command</a>
  20                         <li><a href=#1233707628>04 Feb 2009 New valgrind series</a>
  21                         <li><a href=#1233706294>04 Feb 2009 Problems with split-topic-branches.sh</a>
  22                         <li><a href=#1233277286>30 Jan 2009 More valgrind fun</a>
  23                         <li><a href=#1233193467>29 Jan 2009 Interactive stash</a>
  24                         <li><a href=#1233154567>28 Jan 2009 Splitting topic branches</a>
  25                         </ul></p>
  26                         <a href=dscho.git?a=blob_plain;hb=d764b17bff9cda76d2a6102552a2c49fc5cf953d;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>Thursday, 12th of February, Anno Domini MMIX, at the hour of the Tiger</h6>
  90                         <a name=1234409395>
  91                         <h2>Interactive <i>rebase</i> just learnt a new command: <i>topic</i></h2>
  92
  93                         <p>
  94                         </p><p>
  95                         Today I am pretty pleased with myself.  Two projects at my day job got a real
  96                         boost, and I implemented a shortcut that avoids the ugly 'bookmark' statement
  97                         in rebase scripts most of the time.
  98                         </p><p>
  99                         A typical rebase script, generated by <i>git rebase -i -p $COMMIT</i> will look
 100                         something like this:
 101                         </p><p>
 102                         <table
 103                                                         border=1 bgcolor=black>
 104                                                 <tr><td bgcolor=lightblue colspan=3>
 105                                 <pre>                                                                                </pre>
 106                         </td></tr>
 107                         <tr><td>
 108                                 <table cellspacing=5 border=0
 109                                          style="color:white;">
 110                                 <tr><td>
 111                                         <pre>
 112 pick 1234567 My first commit
 113 topic begin super-cool-feature
 114 pick 2345678 The super cool feature
 115 pick 3456789 Documentation for the super cool feature
 116 topic end super-cool-feature
 117 </pre>
 118                                                         </td></tr>
 119                                                         </table>
 120                                                 </td></tr>
 121                                                 </table>
 122                         </p><p>
 123                         The result will be a merge commit at the HEAD whose first parent is
 124                         "My first commit", whose second parent is "Documentation for the super
 125                         cool feature" and whose commit message is "Merge branch 'super-cool-feature'".
 126                         </p><p>
 127                         Side note: internally, <i>topic begin $NAME [at $COMMIT]</i> will be handled as if
 128                         you wrote <i>bookmark merge-parent-of-$NAME; goto $COMMIT</i>, and
 129                         <i>topic end $NAME [$MESSAGE]</i> will be handled as if you wrote
 130                         <i>bookmark $NAME; goto merge-parent-of-$NAME; merge parents $NAME [original $MARK Merge branch '$NAME']</i>.
 131                         </p><p>
 132                         Of course, being more concise, the 'topic' statement is not only nicer to the
 133                         eye, but also less error-prone.
 134                         </p><p>
 135                         And hopefully many people will agree with me that this rebase script is pretty
 136                         intuitive.
 137                         </p>
 138                         <h6>Wednesday, 11th of February, Anno Domini MMIX, at the hour of the Tiger</h6>
 139                         <a name=1234320806>
 140                         <h2>Thunderbird, oh Thunderbird, you always make my small brain hurt</h2>
 141
 142                         <p>
 143                         </p><p>
 144                         There was a lengthy discussion on the Git mailing list about using Thunderbird,
 145                         a not quite unpopular mailing program, to send inline patches.
 146                         </p><p>
 147                         It is really kind of sad that the Thunderbird developers do not see how
 148                         stubbornly they offend quite a number of people and scare them away from their
 149                         program.  After all, you should try to be liberal in what you accept and strict
 150                         in what you emit.  No, that does not mean that you should force others to
 151                         switch their mailers because you strictly adher to your philosophy in what you
 152                         emit, ignoring the rest of the world.
 153                         </p><p>
 154                         In any case, I am not affected (as long as I do not get mails from a poor soul
 155                         stuck with Thunderbird).
 156                         </p><p>
 157                         But I was a bit mean to that Thunderbird guy I dragged into the discussion, and
 158                         he seems really offended.
 159                         </p><p>
 160                         So I thought I'd give him a real reason to feel offended: I'll just do his work:
 161                         </p><p>
 162                         http://<a href=http://repo.or.cz>repo.or.cz</a>/w/UnFlowedThunderbird.git
 163                         </p><p>
 164                         It took my free time of two days, being not a Thunderbird developer myself.
 165                         Hopefully it works, and hopefully some people will feel really ashamed now.
 166                         </p>
 167                         <h6>Monday, 9th of February, Anno Domini MMIX, at the hour of the Buffalo</h6>
 168                         <a name=1234141489>
 169                         <h2><i>format-patch --thread</i> and Alpine</h2>
 170
 171                         <p>
 172                         </p><p>
 173                         I started recently to pipe the output of
 174                         <i>git format-patch --cover-letter --stdout ...</i> directly into the
 175                         <i>postponed-msgs</i> folder Alpine uses, instead of pasting files into the
 176                         mailer.
 177                         </p><p>
 178                         The idea is to pretend that I continue a postponed mail, but in reality I
 179                         never wrote it, <i>format-patch</i> did.
 180                         </p><p>
 181                         However, I had problems with the <i>--thread</i> option that is implied by
 182                         <i>--cover-letter</i>.  Alpine always generated new message IDs without adjusting
 183                         the <i>In-reply-to:</i> and <i>References:</i> headers of the other mails.
 184                         </p><p>
 185                         Now I found out that the reason is that the <i>Fcc:</i> headers were missing in
 186                         the mails, and Alpine generated them, making up new message IDs in the process.
 187                         </p><p>
 188                         Therefore I have an alias now which sets not only the <i>Fcc:</i> header, but also
 189                         the <i>To:</i> headers by rewriting the stream using <i>sed</i>.  This is slightly
 190                         ugly, but so is the handling of headers in <i>format-patch</i>: if you thought
 191                         you could specify arbitrary headers using the command line, you are mistaken:
 192                         you can do that only by editing the config.
 193                         </p><p>
 194                         While at it, I also noticed a bug whereby <i>--thread --in-reply-to=...</i> simply
 195                         forgets the <i>--thread</i>.  Maybe this week I will find time to address this bug.
 196                         </p>
 197                         <h6>Monday, 9th of February, Anno Domini MMIX, at the hour of the Buffalo</h6>
 198                         <a name=1234140696>
 199                         <h2><i>rebase</i> updates</h2>
 200
 201                         <p>
 202                         </p><p>
 203                         Phew.  The last few days, I was mainly chasing bugs I introduced due to being
 204                         too tired to work on the merge-preserving, interactive <i>rebase</i>.
 205                         </p><p>
 206                         But finally I have something I can start working with.  After my failed
 207                         experiment to use git-blame to split topic branches, I will sort the commits
 208                         in my <i>my-next</i> branch into topic branches manually.
 209                         </p><p>
 210                         Then I will add an option to <i>rebase -i -p</i> to rewrite refs which point to
 211                         rewritten commits, so that I can have branches <i>rebase-i-p</i>, <i>add-e</i>, etc
 212                         and all of them are automatically updated when I <i>rebase -i -p</i> the <i>my-next</i>
 213                         branch.
 214                         </p><p>
 215                         In the process, not only have I learnt the value of the <i>bookmark</i> command,
 216                         but made quite a few-much needed cleanups (which make
 217                         <i>git-rebase--interactive.sh</i> longer, but much more understandable).
 218                         </p><p>
 219                         Hopefully Stephan will pick the changes in the "rebase protocol" up, and then
 220                         we can have a sequencer with which I can start to make a graphical interactive
 221                         rebase using git-gui.  Or gitk.
 222                         </p><p>
 223                         Maybe.
 224                         </p>
 225                         <h6>Saturday, 7th of February, Anno Domini MMIX, at the hour of the Pig</h6>
 226                         <a name=1234040744>
 227                         <h2>The infamous <i>mark</i> command in the <i>rebase</i> command</h2>
 228
 229                         <p>
 230                         </p><p>
 231                         I realized today how easy it is to lose commits with the "merge preserving"
 232                         mode of the interactive rebase.  In my case, it was when I tried to move a
 233                         bunch of commits from the tip of my branch into a topic branch.
 234                         </p><p>
 235                         But after moving the commits, I forgot to update the parent of the merge
 236                         commit.  Possibly a mark command could have helped.  The very same command
 237                         I called a nightmare for usability.
 238                         </p><p>
 239                         So I was wrong.  Big news.  &#x263a;
 240                         </p><p>
 241                         However, I think that the syntax "mark :1" is something best left for
 242                         machine consumption, not for human beings.
 243                         </p><p>
 244                         But I have an idea: we could use some garbled commit subject, or in case of
 245                         merge parents, the merge subject as some human readable title of the mark.
 246                         </p><p>
 247                         The rebase script would then look something like this:
 248                         </p><p>
 249                         <table
 250                                                         border=1 bgcolor=black>
 251                                                 <tr><td bgcolor=lightblue colspan=3>
 252                                 <pre>                                                                                </pre>
 253                         </td></tr>
 254                         <tr><td>
 255                                 <table cellspacing=5 border=0
 256                                          style="color:white;">
 257                                 <tr><td>
 258                                         <pre>
 259 pick abcdefg Some ultra cool commit
 260 bookmark ultra-cool
 261 goto upstream
 262 pick hijklmn Some other cool commit
 263 merge parent ultra-cool Merge 'ultra-cool' into master
 264 </pre>
 265                                                         </td></tr>
 266                                                         </table>
 267                                                 </td></tr>
 268                                                 </table>
 269                         </p><p>
 270                         The good news is: I added code that refuses to finish a rebase when there
 271                         are commits that were rewritten, but not part of the new HEAD's ancestry.
 272                         </p>
 273                         <h6>Wednesday, 4th of February, Anno Domini MMIX, at the hour of the Buffalo</h6>
 274                         <a name=1233707628>
 275                         <h2>New valgrind series</h2>
 276
 277                         <p>
 278                         </p><p>
 279                         I spent quite some time cleaning up that patch series, and feel pretty
 280                         exhausted.
 281                         </p><p>
 282                         Granted, the new <i>git rebase -i -p</i> does its job without complaint so far
 283                         (so much so that I think I'll release a version of my <i>rebase</i> series
 284                         soonish), but it <u>is</u> a hassle when you have patches that you have a hard
 285                         time to decide upon the order/commit boundaries.
 286                         </p><p>
 287                         For example, I could imagine that the patch making the location of the
 288                         templates independent of the location of the Git binaries should come
 289                         <u>before</u> my patch series, and the valgrind specific part should then
 290                         be squashed into the first valgrind commit.
 291                         </p><p>
 292                         Also, it uses two features of valgrind 3.4.0:
 293                         </p><p>
 294                         <ul>
 295                         <li><i>...</i> in the suppression file, and
 296                         <li><i>--track-origins=yes</i>
 297                         </ul>
 298                         </p><p>
 299                         The latter is actually the reason I am pretty willing to keep the
 300                         requirement of that valgrind version, as it is really, really useful.
 301                         </p><p>
 302                         I guess we will see what happens to it.
 303                         </p>
 304                         <h6>Wednesday, 4th of February, Anno Domini MMIX, at the hour of the Buffalo</h6>
 305                         <a name=1233706294>
 306                         <h2>Problems with split-topic-branches.sh</h2>
 307
 308                         <p>
 309                         </p><p>
 310                         So my little script that should help me to split my topic branches does
 311                         not work properly.
 312                         </p><p>
 313                         First some background: the idea was to let <i>git blame</i> do the hard work
 314                         to find overlapping changes, i.e. changes that would conflict when
 315                         changing the order (or skipping the first change, on which the next builds).
 316                         </p><p>
 317                         The first problem with that approach: when lines are <u>removed</u> by one
 318                         commit, and the next commit touches the same location, <i>git blame</i> does
 319                         not find that the first commit is required by the second.
 320                         </p><p>
 321                         Therefore I introduced a really slow reverse thing which tries to find
 322                         those commits whose removals survived until the parent of a particular
 323                         commit, but not further.
 324                         </p><p>
 325                         However, it does not work properly.  Basically, only context sizes that
 326                         span the whole files lead to conflict-free topic branches so far.
 327                         </p><p>
 328                         As a consequence, I think I'll add an option --sprout to the revision
 329                         walker which will fake octopus merges (or a series of two-parent merges)
 330                         whenever it finds a perl of non-merge commits that are theoretically
 331                         independent, i.e. whose patches apply cleanly.
 332                         </p>
 333                         <h6>Friday, 30th of January, Anno Domini MMIX, at the hour of the Buffalo</h6>
 334                         <a name=1233277286>
 335                         <h2>More valgrind fun</h2>
 336
 337                         <p>
 338                         </p><p>
 339                         So I spent quite a number of hours on that funny zlib/valgrind issue.  The
 340                         thing is, zlib people claim that even if their code accesses uninitialized
 341                         memory, it does not produce erroneous data (by cutting out the results of the
 342                         uninitialized data, which is cheaper than checking for the end of the buffer
 343                         in an unaligned manner), so zlib will always be special for valgrind.
 344                         </p><p>
 345                         However, the bug I was chasing is funny, and different from said issue.  zlib
 346                         deflates an input buffer to an output buffer that is exactly 58 bytes long.
 347                         But valgrind claims that the 52nd of those bytes is uninitialized, and <u>only</u>
 348                         that one.
 349                         </p><p>
 350                         But it is not.  It must be 0x2c, otherwise zlib refuses to inflate the
 351                         buffer.
 352                         </p><p>
 353                         Now, I went into a debugging frenzy, and finally found out that zlib just
 354                         passes fine (with the default suppressions because of the "cute" way it
 355                         uses uninitialized memory), <u>except</u> when it is compiled with UNALIGNED_OK
 356                         defined.
 357                         </p><p>
 358                         Which Ubuntu does, of course.  Ubuntu, the biggest forker of all.
 359                         </p><p>
 360                         The bad part is that it sounds like a bug in valgrind, and I <u>could</u> imagine
 361                         that it is an issue of an optimized memcpy() that copies int by int, and
 362                         that valgrind misses out on the fact that a part of that int is actually
 363                         <u>not</u> uninitialized.
 364                         </p><p>
 365                         But my debugging session's results disagree with that.
 366                         </p><p>
 367                         With the help of Julian Seward, the original author of valgrind, I instrumented
 368                         zlib's source code so that valgrind checks earlier if the byte is initialized
 369                         or not, to find out where the reason of the issue lies.
 370                         </p><p>
 371                         The sad part is that when I added the instrumentation to both the <u>end</u> of
 372                         the while() loop in compress_block() in zlib's trees.c, and just <u>after</u> the
 373                         while() loop (whose condition is a plain <i>variable < variable</i> comparison,
 374                         nothing fancy, certainly not changing any memory), only the <u>latter</u> catches
 375                         a valgrind error.
 376                         </p><p>
 377                         And that is truly strange.
 378                         </p>
 379                         <h6>Thursday, 29th of January, Anno Domini MMIX, at the hour of the Buffalo</h6>
 380                         <a name=1233193467>
 381                         <h2>Interactive stash</h2>
 382
 383                         <p>
 384                         </p><p>
 385                         There is an easy way to split a patch:
 386                         </p><p>
 387                         <table
 388                                                         border=1 bgcolor=black>
 389                                                 <tr><td bgcolor=lightblue colspan=3>
 390                                 <pre>                                                                                </pre>
 391                         </td></tr>
 392                         <tr><td>
 393                                 <table cellspacing=5 border=0
 394                                          style="color:white;">
 395                                 <tr><td>
 396                                         <pre>
 397 $ git reset HEAD^
 398 $ git add -i
 399 $ git commit
 400 $ git diff -R HEAD@{1} | git apply --index
 401 $ git commit
 402 </pre>
 403                                                         </td></tr>
 404                                                         </table>
 405                                                 </td></tr>
 406                                                 </table>
 407                         </p><p>
 408                         but it misses out on the fact that the first of both commits does not
 409                         reflect the state of the working directory at any time.
 410                         </p><p>
 411                         So I think something like an interactive <i>stash</i> is needed.  A method
 412                         to specify what you want to keep in the working directory, the rest should
 413                         be stashed.  The idea would be something like this:
 414                         </p><p>
 415                         <ol>
 416                         <li>Add the desired changes into a temporary index.
 417                         <li>Put the rest of the changes in another temporary index.
 418                         <li>Stash the latter index.
 419                         <li>Synchronize the working directory with the first index.
 420                         <li>Clean up temporary indices.
 421                         </ol>
 422                         </p><p>
 423                         Or in code:
 424                         </p><p>
 425                         <table
 426                                                         border=1 bgcolor=black>
 427                                                 <tr><td bgcolor=lightblue colspan=3>
 428                                 <pre>                                                                                </pre>
 429                         </td></tr>
 430                         <tr><td>
 431                                 <table cellspacing=5 border=0
 432                                          style="color:white;">
 433                                 <tr><td>
 434                                         <pre>
 435 $ cp .git/index .git/interactive-stash-1
 436 $ GIT_INDEX_FILE=.git/interactive-stash-1 git add -i
 437 $ cp .git/index .git/interactive-stash-2
 438 $ GIT_INDEX_FILE=.git/interactive-stash-1 git diff -R |
 439         (GIT_INDEX_FILE=.git/interactive-stash-2 git apply--index)
 440 $ tree=$(GIT_INDEX_FILE=.git/index git write-tree)
 441 $ commit=$(echo Current index | git commit-tree $tree -p HEAD)
 442 $ tree=$(GIT_INDEX_FILE=.git/interactive-stash-2 git write-tree)
 443 $ commit=$(echo Edited out | git commit-tree $tree -p HEAD -p $commit)
 444 $ git update-ref refs/stash $commit
 445 $ GIT_INDEX_FILE=.git/interactive-stash-1 git checkout-index -a -f
 446 $ rm .git/interactive-stash-1 .git/interactive-stash-2
 447 </pre>
 448                                                         </td></tr>
 449                                                         </table>
 450                                                 </td></tr>
 451                                                 </table>
 452                         </p><p>
 453                         This should probably go into <i>git-stash.sh</i>, maybe even with a switch
 454                         to start git-gui to do the interactive adding instead of git-add.
 455                         </p>
 456                         <h6>Wednesday, 28th of January, Anno Domini MMIX, at the hour of the Monkey</h6>
 457                         <a name=1233154567>
 458                         <h2>Splitting topic branches</h2>
 459
 460                         <p>
 461                         </p><p>
 462                         One might be put off easily by the overarching use of buzzwords in the
 463                         description of how <i>Darcs</i> works.  I, for one, do not expect an intelligent
 464                         author when I read <i>Theory of patches</i> and <i>based on quantum physics</i>.
 465                         </p><p>
 466                         The true story, however, is much simpler, and is actually not that dumb:
 467                         Let's call two commits "conflicting" when they contain at least one
 468                         overlapping change.
 469                         </p><p>
 470                         The idea is now: Given a list of commits (not a set, as the order is important),
 471                         to sort them into smaller lists such that conflicting commits are in the
 472                         sublists ("topic branches") and the sublists are minimal, i.e. no two
 473                         non-conflicting commits are in the same sublist.
 474                         </p><p>
 475                         The idea has flaws, of course, as you can have a patch changing the code,
 476                         and another changing the documentation, but splitting a list of commits
 477                         in that way is a first step to sort out my <i>my-next</i> mess, where I have
 478                         a linear perl of not-necessarily-dependent commits.
 479                         </p><p>
 480                         And actually, my whole rebase revamp aimed at the clean-up for my own
 481                         <i>my-next</i> branch, so I am currently writing a script that can be used
 482                         as a GIT_EDITOR for git-rebase which implements the Darcs algorithm.  Kind of:
 483                         the result is not implicit, but explicit and can be fixed up later.
 484                         </p>
 485                 </div>
 486         </body>
 487 </html>