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=#1234140696>09 Feb 2009 <i>rebase</i> updates</a>
  16                         <li><a href=#1234040744>07 Feb 2009 The infamous <i>mark</i> command in the <i>rebase</i> command</a>
  17                         <li><a href=#1233707628>04 Feb 2009 New valgrind series</a>
  18                         <li><a href=#1233706294>04 Feb 2009 Problems with split-topic-branches.sh</a>
  19                         <li><a href=#1233277286>30 Jan 2009 More valgrind fun</a>
  20                         <li><a href=#1233193467>29 Jan 2009 Interactive stash</a>
  21                         <li><a href=#1233154567>28 Jan 2009 Splitting topic branches</a>
  22                         <li><a href=#1233102919>28 Jan 2009 Showing off that you're an Alpine user ... priceless!</a>
  23                         <li><a href=#1233101919>28 Jan 2009 Progress with the interactive rebase preserving merges</a>
  24                         <li><a href=#1233099894>28 Jan 2009 Another midnight riddle?</a>
  25                         </ul></p>
  26                         <a href=dscho.git?a=blob_plain;hb=f040c492d180218c48700a4b35c3a6186c5373f1;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>Monday, 9th of February, Anno Domini MMIX, at the hour of the Buffalo</h6>
  90                         <a name=1234140696>
  91                         <h2><i>rebase</i> updates</h2>
  92
  93                         <p>
  94                         </p><p>
  95                         Phew.  The last few days, I was mainly chasing bugs I introduced due to being
  96                         too tired to work on the merge-preserving, interactive <i>rebase</i>.
  97                         </p><p>
  98                         But finally I have something I can start working with.  After my failed
  99                         experiment to use git-blame to split topic branches, I will sort the commits
 100                         in my <i>my-next</i> branch into topic branches manually.
 101                         </p><p>
 102                         Then I will add an option to <i>rebase -i -p</i> to rewrite refs which point to
 103                         rewritten commits, so that I can have branches <i>rebase-i-p</i>, <i>add-e</i>, etc
 104                         and all of them are automatically updated when I <i>rebase -i -p</i> the <i>my-next</i>
 105                         branch.
 106                         </p><p>
 107                         In the process, not only have I learnt the value of the <i>bookmark</i> command,
 108                         but made quite a few-much needed cleanups (which make
 109                         <i>git-rebase--interactive.sh</i> longer, but much more understandable).
 110                         </p><p>
 111                         Hopefully Stephan will pick the changes in the "rebase protocol" up, and then
 112                         we can have a sequencer with which I can start to make a graphical interactive
 113                         rebase using git-gui.  Or gitk.
 114                         </p><p>
 115                         Maybe.
 116                         </p>
 117                         <h6>Saturday, 7th of February, Anno Domini MMIX, at the hour of the Pig</h6>
 118                         <a name=1234040744>
 119                         <h2>The infamous <i>mark</i> command in the <i>rebase</i> command</h2>
 120
 121                         <p>
 122                         </p><p>
 123                         I realized today how easy it is to lose commits with the "merge preserving"
 124                         mode of the interactive rebase.  In my case, it was when I tried to move a
 125                         bunch of commits from the tip of my branch into a topic branch.
 126                         </p><p>
 127                         But after moving the commits, I forgot to update the parent of the merge
 128                         commit.  Possibly a mark command could have helped.  The very same command
 129                         I called a nightmare for usability.
 130                         </p><p>
 131                         So I was wrong.  Big news.  &#x263a;
 132                         </p><p>
 133                         However, I think that the syntax "mark :1" is something best left for
 134                         machine consumption, not for human beings.
 135                         </p><p>
 136                         But I have an idea: we could use some garbled commit subject, or in case of
 137                         merge parents, the merge subject as some human readable title of the mark.
 138                         </p><p>
 139                         The rebase script would then look something like this:
 140                         </p><p>
 141                         <table
 142                                                         border=1 bgcolor=black>
 143                                                 <tr><td bgcolor=lightblue colspan=3>
 144                                 <pre>                                                                                </pre>
 145                         </td></tr>
 146                         <tr><td>
 147                                 <table cellspacing=5 border=0
 148                                          style="color:white;">
 149                                 <tr><td>
 150                                         <pre>
 151 pick abcdefg Some ultra cool commit
 152 bookmark ultra-cool
 153 goto upstream
 154 pick hijklmn Some other cool commit
 155 merge parent ultra-cool Merge 'ultra-cool' into master
 156 </pre>
 157                                                         </td></tr>
 158                                                         </table>
 159                                                 </td></tr>
 160                                                 </table>
 161                         </p><p>
 162                         The good news is: I added code that refuses to finish a rebase when there
 163                         are commits that were rewritten, but not part of the new HEAD's ancestry.
 164                         </p>
 165                         <h6>Wednesday, 4th of February, Anno Domini MMIX, at the hour of the Buffalo</h6>
 166                         <a name=1233707628>
 167                         <h2>New valgrind series</h2>
 168
 169                         <p>
 170                         </p><p>
 171                         I spent quite some time cleaning up that patch series, and feel pretty
 172                         exhausted.
 173                         </p><p>
 174                         Granted, the new <i>git rebase -i -p</i> does its job without complaint so far
 175                         (so much so that I think I'll release a version of my <i>rebase</i> series
 176                         soonish), but it <u>is</u> a hassle when you have patches that you have a hard
 177                         time to decide upon the order/commit boundaries.
 178                         </p><p>
 179                         For example, I could imagine that the patch making the location of the
 180                         templates independent of the location of the Git binaries should come
 181                         <u>before</u> my patch series, and the valgrind specific part should then
 182                         be squashed into the first valgrind commit.
 183                         </p><p>
 184                         Also, it uses two features of valgrind 3.4.0:
 185                         </p><p>
 186                         <ul>
 187                         <li><i>...</i> in the suppression file, and
 188                         <li><i>--track-origins=yes</i>
 189                         </ul>
 190                         </p><p>
 191                         The latter is actually the reason I am pretty willing to keep the
 192                         requirement of that valgrind version, as it is really, really useful.
 193                         </p><p>
 194                         I guess we will see what happens to it.
 195                         </p>
 196                         <h6>Wednesday, 4th of February, Anno Domini MMIX, at the hour of the Buffalo</h6>
 197                         <a name=1233706294>
 198                         <h2>Problems with split-topic-branches.sh</h2>
 199
 200                         <p>
 201                         </p><p>
 202                         So my little script that should help me to split my topic branches does
 203                         not work properly.
 204                         </p><p>
 205                         First some background: the idea was to let <i>git blame</i> do the hard work
 206                         to find overlapping changes, i.e. changes that would conflict when
 207                         changing the order (or skipping the first change, on which the next builds).
 208                         </p><p>
 209                         The first problem with that approach: when lines are <u>removed</u> by one
 210                         commit, and the next commit touches the same location, <i>git blame</i> does
 211                         not find that the first commit is required by the second.
 212                         </p><p>
 213                         Therefore I introduced a really slow reverse thing which tries to find
 214                         those commits whose removals survived until the parent of a particular
 215                         commit, but not further.
 216                         </p><p>
 217                         However, it does not work properly.  Basically, only context sizes that
 218                         span the whole files lead to conflict-free topic branches so far.
 219                         </p><p>
 220                         As a consequence, I think I'll add an option --sprout to the revision
 221                         walker which will fake octopus merges (or a series of two-parent merges)
 222                         whenever it finds a perl of non-merge commits that are theoretically
 223                         independent, i.e. whose patches apply cleanly.
 224                         </p>
 225                         <h6>Friday, 30th of January, Anno Domini MMIX, at the hour of the Buffalo</h6>
 226                         <a name=1233277286>
 227                         <h2>More valgrind fun</h2>
 228
 229                         <p>
 230                         </p><p>
 231                         So I spent quite a number of hours on that funny zlib/valgrind issue.  The
 232                         thing is, zlib people claim that even if their code accesses uninitialized
 233                         memory, it does not produce erroneous data (by cutting out the results of the
 234                         uninitialized data, which is cheaper than checking for the end of the buffer
 235                         in an unaligned manner), so zlib will always be special for valgrind.
 236                         </p><p>
 237                         However, the bug I was chasing is funny, and different from said issue.  zlib
 238                         deflates an input buffer to an output buffer that is exactly 58 bytes long.
 239                         But valgrind claims that the 52nd of those bytes is uninitialized, and <u>only</u>
 240                         that one.
 241                         </p><p>
 242                         But it is not.  It must be 0x2c, otherwise zlib refuses to inflate the
 243                         buffer.
 244                         </p><p>
 245                         Now, I went into a debugging frenzy, and finally found out that zlib just
 246                         passes fine (with the default suppressions because of the "cute" way it
 247                         uses uninitialized memory), <u>except</u> when it is compiled with UNALIGNED_OK
 248                         defined.
 249                         </p><p>
 250                         Which Ubuntu does, of course.  Ubuntu, the biggest forker of all.
 251                         </p><p>
 252                         The bad part is that it sounds like a bug in valgrind, and I <u>could</u> imagine
 253                         that it is an issue of an optimized memcpy() that copies int by int, and
 254                         that valgrind misses out on the fact that a part of that int is actually
 255                         <u>not</u> uninitialized.
 256                         </p><p>
 257                         But my debugging session's results disagree with that.
 258                         </p><p>
 259                         With the help of Julian Seward, the original author of valgrind, I instrumented
 260                         zlib's source code so that valgrind checks earlier if the byte is initialized
 261                         or not, to find out where the reason of the issue lies.
 262                         </p><p>
 263                         The sad part is that when I added the instrumentation to both the <u>end</u> of
 264                         the while() loop in compress_block() in zlib's trees.c, and just <u>after</u> the
 265                         while() loop (whose condition is a plain <i>variable < variable</i> comparison,
 266                         nothing fancy, certainly not changing any memory), only the <u>latter</u> catches
 267                         a valgrind error.
 268                         </p><p>
 269                         And that is truly strange.
 270                         </p>
 271                         <h6>Thursday, 29th of January, Anno Domini MMIX, at the hour of the Buffalo</h6>
 272                         <a name=1233193467>
 273                         <h2>Interactive stash</h2>
 274
 275                         <p>
 276                         </p><p>
 277                         There is an easy way to split a patch:
 278                         </p><p>
 279                         <table
 280                                                         border=1 bgcolor=black>
 281                                                 <tr><td bgcolor=lightblue colspan=3>
 282                                 <pre>                                                                                </pre>
 283                         </td></tr>
 284                         <tr><td>
 285                                 <table cellspacing=5 border=0
 286                                          style="color:white;">
 287                                 <tr><td>
 288                                         <pre>
 289 $ git reset HEAD^
 290 $ git add -i
 291 $ git commit
 292 $ git diff -R HEAD@{1} | git apply --index
 293 $ git commit
 294 </pre>
 295                                                         </td></tr>
 296                                                         </table>
 297                                                 </td></tr>
 298                                                 </table>
 299                         </p><p>
 300                         but it misses out on the fact that the first of both commits does not
 301                         reflect the state of the working directory at any time.
 302                         </p><p>
 303                         So I think something like an interactive <i>stash</i> is needed.  A method
 304                         to specify what you want to keep in the working directory, the rest should
 305                         be stashed.  The idea would be something like this:
 306                         </p><p>
 307                         <ol>
 308                         <li>Add the desired changes into a temporary index.
 309                         <li>Put the rest of the changes in another temporary index.
 310                         <li>Stash the latter index.
 311                         <li>Synchronize the working directory with the first index.
 312                         <li>Clean up temporary indices.
 313                         </ol>
 314                         </p><p>
 315                         Or in code:
 316                         </p><p>
 317                         <table
 318                                                         border=1 bgcolor=black>
 319                                                 <tr><td bgcolor=lightblue colspan=3>
 320                                 <pre>                                                                                </pre>
 321                         </td></tr>
 322                         <tr><td>
 323                                 <table cellspacing=5 border=0
 324                                          style="color:white;">
 325                                 <tr><td>
 326                                         <pre>
 327 $ cp .git/index .git/interactive-stash-1
 328 $ GIT_INDEX_FILE=.git/interactive-stash-1 git add -i
 329 $ cp .git/index .git/interactive-stash-2
 330 $ GIT_INDEX_FILE=.git/interactive-stash-1 git diff -R |
 331         (GIT_INDEX_FILE=.git/interactive-stash-2 git apply--index)
 332 $ tree=$(GIT_INDEX_FILE=.git/index git write-tree)
 333 $ commit=$(echo Current index | git commit-tree $tree -p HEAD)
 334 $ tree=$(GIT_INDEX_FILE=.git/interactive-stash-2 git write-tree)
 335 $ commit=$(echo Edited out | git commit-tree $tree -p HEAD -p $commit)
 336 $ git update-ref refs/stash $commit
 337 $ GIT_INDEX_FILE=.git/interactive-stash-1 git checkout-index -a -f
 338 $ rm .git/interactive-stash-1 .git/interactive-stash-2
 339 </pre>
 340                                                         </td></tr>
 341                                                         </table>
 342                                                 </td></tr>
 343                                                 </table>
 344                         </p><p>
 345                         This should probably go into <i>git-stash.sh</i>, maybe even with a switch
 346                         to start git-gui to do the interactive adding instead of git-add.
 347                         </p>
 348                         <h6>Wednesday, 28th of January, Anno Domini MMIX, at the hour of the Monkey</h6>
 349                         <a name=1233154567>
 350                         <h2>Splitting topic branches</h2>
 351
 352                         <p>
 353                         </p><p>
 354                         One might be put off easily by the overarching use of buzzwords in the
 355                         description of how <i>Darcs</i> works.  I, for one, do not expect an intelligent
 356                         author when I read <i>Theory of patches</i> and <i>based on quantum physics</i>.
 357                         </p><p>
 358                         The true story, however, is much simpler, and is actually not that dumb:
 359                         Let's call two commits "conflicting" when they contain at least one
 360                         overlapping change.
 361                         </p><p>
 362                         The idea is now: Given a list of commits (not a set, as the order is important),
 363                         to sort them into smaller lists such that conflicting commits are in the
 364                         sublists ("topic branches") and the sublists are minimal, i.e. no two
 365                         non-conflicting commits are in the same sublist.
 366                         </p><p>
 367                         The idea has flaws, of course, as you can have a patch changing the code,
 368                         and another changing the documentation, but splitting a list of commits
 369                         in that way is a first step to sort out my <i>my-next</i> mess, where I have
 370                         a linear perl of not-necessarily-dependent commits.
 371                         </p><p>
 372                         And actually, my whole rebase revamp aimed at the clean-up for my own
 373                         <i>my-next</i> branch, so I am currently writing a script that can be used
 374                         as a GIT_EDITOR for git-rebase which implements the Darcs algorithm.  Kind of:
 375                         the result is not implicit, but explicit and can be fixed up later.
 376                         </p>
 377                         <h6>Wednesday, 28th of January, Anno Domini MMIX, at the hour of the Buffalo</h6>
 378                         <a name=1233102919>
 379                         <h2>Showing off that you're an Alpine user ... priceless!</h2>
 380
 381                         <p>
 382                         </p><p>
 383                         So I was in a hurry to send the patches, and sent all the patches as replies
 384                         to the cover-letter, and therefore typed in <i>rnyn</i> all the time, which is the
 385                         mantra I need to say to Alpine for <i>Reply</i>, ... include quoted message?
 386                         <i>No</i>, ... reply to all recipients? <i>Yes</i>, ... use first role?
 387                         <i>No, use default role</i>.
 388                         </p><p>
 389                         That was pretty embarassing, as it shows everybody that I still do not trust
 390                         <i>send-email</i>, and rather paste every single patch by hand.  Which is rather
 391                         annoying.
 392                         </p><p>
 393                         So I started using format-patch today, to output directly to Alpine's
 394                         <i>postponed-msgs</i> folder, so that I can do some touchups in the mailer
 395                         before sending the patch series on its way.
 396                         </p><p>
 397                         However, when running format-patch with <i>--thread</i>, it generates Message-ID
 398                         strings that Alpine does not like, and therefore replaces.
 399                         </p><p>
 400                         Oh, well, I'll probably just investigate how the Message-IDs are supposed to
 401                         look, and then use sed to rewrite the generated ones by Alpine-friendly ones
 402                         during the redirection to <i>postponed-msgs</i>.
 403                         </p><p>
 404                         But I alread realized that doing it that way is dramatically faster than the
 405                         workflow I had before.
 406                         </p><p>
 407                         And safer: no more <i>rnyn</i>.
 408                         </p>
 409                         <h6>Wednesday, 28th of January, Anno Domini MMIX, at the hour of the Buffalo</h6>
 410                         <a name=1233101919>
 411                         <h2>Progress with the interactive rebase preserving merges</h2>
 412
 413                         <p>
 414                         </p><p>
 415                         I thought about the "dropped" commits a bit more, after all, and it is
 416                         probably a good thing to substitute them by their parent, as Stephen did it.
 417                         </p><p>
 418                         Imagine that you have merged a branch with two commits.  One is in upstream,
 419                         and you want to rebase (preserving merges) onto upstream.  Then you still
 420                         want to merge the single commit.
 421                         </p><p>
 422                         Even better, if there is no commit left, the <i>$REWRITTEN</i> mechanism will
 423                         substitute the commit onto which we are rebasing, so a merge will just
 424                         result in a fast-forward!
 425                         </p><p>
 426                         Oh, another thing: merge commits should not have a patch id, as they have
 427                         <u>multiple</u> patches.  However, I borked the code long time ago (9c6efa36)
 428                         and merges get the patch-id of their diff to the first parent.  Which is
 429                         probably wrong.  So I guess I'll have to fix that with my rebase revamp.
 430                         </p><p>
 431                         So what about a root commit?  If that was dropped, we will just substitute
 432                         it with the commit onto which we rebase (as a root commit did not really
 433                         have a parent, but will get the onto-commit as new parent)..
 434                         </p><p>
 435                         Now that I finally realized that t3410 is so strange because of a bug <u>I</u>
 436                         introduced, I can finally go about fixing it.
 437                         </p>
 438                         <h6>Wednesday, 28th of January, Anno Domini MMIX, at the hour of the Rat</h6>
 439                         <a name=1233099894>
 440                         <h2>Another midnight riddle?</h2>
 441
 442                         <p>
 443                         </p><p>
 444                         Okay, here's another riddle: what is the next line?
 445                         </p><p>
 446 <pre>
 447        1
 448       1 1
 449       2 1
 450     1 1 1 2
 451     3 1 1 2
 452   2 1 1 2 1 3
 453 ...
 454 </pre>
 455                         </p><p>
 456                         And when does the line get wider than 10 digits?
 457                         </p>
 458                 </div>
 459         </body>
 460 </html>