index.html

   1 <html>
   2         <head>
   3                 <title>Dscho's blog</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=aaa9edafbe6ca5349ad7b36848fb294e5f4fc529;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 blog</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=#1233101919>28 Jan 2009 Progress with the interactive rebase preserving merges</a>
  16                         <li><a href=#1233099894>28 Jan 2009 Another midnight riddle?</a>
  17                         <li><a href=#1233022809>27 Jan 2009 Fun with calculus after midnight</a>
  18                         <li><a href=#1232997290>26 Jan 2009 Valgrind takes a loooong time</a>
  19                         <li><a href=#1232927812>26 Jan 2009 A day full of rebase... and a little valgrind</a>
  20                         <li><a href=#1232888842>25 Jan 2009 Regular diff with word coloring (as opposed to word diff)</a>
  21                         <li><a href=#1232828715>24 Jan 2009 Ideas for a major revamp of the <i>--preserve-merges</i> handling in <i>git rebase</i></a>
  22                         <li><a href=#1232778113>24 Jan 2009 Thoughts about <i>interactive rebase</i></a>
  23                         <li><a href=#1232745071>23 Jan 2009 Git Logos</a>
  24                         <li><a href=#1232742582>23 Jan 2009 How to deal with files that are not source code when merging</a>
  25                         </ul></p>
  26                         <a href=dscho.git?a=blob_plain;hb=2d0d8b3bf30f6803b679342cb91225746af5376a;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;f=source-1232626236.txt;h=1edde0467a>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>Wednesday, 28th of January, Anno Domini MMIX, at the hour of the Buffalo</h6>
  90                         <a name=1233101919>
  91                         <h2>Progress with the interactive rebase preserving merges</h2>
  92
  93                         <p>
  94                         </p><p>
  95                         I thought about the "dropped" commits a bit more, after all, and it is
  96                         probably a good thing to substitute them by their parent, as Stephen did it.
  97                         </p><p>
  98                         Imagine that you have merged a branch with two commits.  One is in upstream,
  99                         and you want to rebase (preserving merges) onto upstream.  Then you still
 100                         want to merge the single commit.
 101                         </p><p>
 102                         Even better, if there is no commit left, the <i>$REWRITTEN</i> mechanism will
 103                         substitute the commit onto which we are rebasing, so a merge will just
 104                         result in a fast-forward!
 105                         </p><p>
 106                         Oh, another thing: merge commits can never be dropped (as that would mean
 107                         that the patch id of that commit is identical to a patch id of a commit in
 108                         the upstream branch; but merge commits do not have a single patch, let alone
 109                         a patch id).  So we can be certain that a dropped commit always has at most
 110                         one parent.
 111                         </p><p>
 112                         So what about a root commit?  If that was dropped, we will just substitute
 113                         it with the commit onto which we rebase.
 114                         </p><p>
 115                         The thing that upset me a bit when I found out about it, is what t3410 is
 116                         all about.  It speaks about dropping local merges together with their
 117                         <u>whole</u> branches when an upstream has the same "merge resolution".
 118                         </p><p>
 119                         To my surprise, Stephen had no objections to remove that stuff, so I think
 120                         I'll be able to submit something usable tomorrow.
 121                         </p><p>
 122                         Or maybe I will start to use it first...
 123                         </p><p>
 124                         Another thought that occurred to me is that I could include the output of
 125                         <i>git log --graph</i>.  This cannot be done in the rebase script directly,
 126                         as there are "goto" and "merge" statements disrupting the graph, and
 127                         besides, it would look ugly if you reordered commits without adjusting the
 128                         graph, so I may include the graph (for <i>-p</i> only) in the comment section.
 129                         </p>
 130                         <h6>Wednesday, 28th of January, Anno Domini MMIX, at the hour of the Rat</h6>
 131                         <a name=1233099894>
 132                         <h2>Another midnight riddle?</h2>
 133
 134                         <p>
 135                         </p><p>
 136                         Okay, here's another riddle: what is the next line?
 137                         </p><p>
 138 <pre>
 139        1
 140       1 1
 141       2 1
 142     1 1 1 2
 143     3 1 1 2
 144   2 1 1 2 1 3
 145 ...
 146 </pre>
 147                         </p><p>
 148                         And when does the line get wider than 10 digits?
 149                         </p>
 150                         <h6>Tuesday, 27th of January, Anno Domini MMIX, at the hour of the Tiger</h6>
 151                         <a name=1233022809>
 152                         <h2>Fun with calculus after midnight</h2>
 153
 154                         <p>
 155                         </p><p>
 156                         Problem: what is the shortest way of defining a variable consisting of <i>N</i>
 157                         spaces?  I.e. for <i>N=80</i> the result will look something like
 158                         </p><p>
 159                         <table
 160                                                         border=1 bgcolor=black>
 161                                                 <tr><td bgcolor=lightblue colspan=3>
 162                                 <pre>                                                                                </pre>
 163                         </td></tr>
 164                         <tr><td>
 165                                 <table cellspacing=5 border=0
 166                                          style="color:white;">
 167                                 <tr><td>
 168                                         <pre>
 169 s='    '
 170 s="$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s"
 171 </pre>
 172                                                         </td></tr>
 173                                                         </table>
 174                                                 </td></tr>
 175                                                 </table>
 176                         </p><p>
 177                         Let's see.  Let the minimal number of characters needed be <i>A(N)</i>.  For
 178                         simplicity, let's say that we only use one variable.  Then, certainly, <i>A(N)</i>
 179                         cannot be larger than <i>5+N</i>, as we could define a variable using 1 character
 180                         for the name, 1 for the equal sign, 2 for the quotes, and one for the semicolon
 181                         or newline character (whichever).
 182                         </p><p>
 183                         Now, let's assume <i>N</i> is a product <i>K*L</i>.  Then certainly, <i>A(N)</i> cannot
 184                         be larger than <i>A(K)+5+2*L</i>, as we could first define a variable that has
 185                         exactly <i>K</i> spaces and then use that to define the end result (in the example
 186                         above, <i>K=5</i> and <i>L=20</i>).
 187                         </p><p>
 188                         So, for which <i>N=K*L</i> is it better to use two definitions instead of one?
 189                         </p><p>
 190                         Simple calculus says that <i>5+K*L>5+K+5+2*L</i> must hold true, or (after some
 191                         scribbling): <i>L>1+7/(K-2)</i>. Which means that it makes no sense to define
 192                         a variable with 1 or 2 spaces first, which is kinda obvious (writing '$s'
 193                         alone would use two characters, so we could write the spaces right away).
 194                         </p><p>
 195                         But what for the other values?  For <i>K=3</i>, <i>L</i> must be at least 9 to make
 196                         sense (in other words, <i>N</i> must be at least 27).  For <i>K=4</i>, <i>L</i> needs
 197                         to be greater or equal to 5 (<i>N>=20</i>), the next pairs are <i>(5,4)</i>,
 198                         <i>(6,3)</i>, <i>(7,3)</i>, <i>(8,3)</i>, <i>(9,3)</i> and starting with <i>K=10</i>, any
 199                         <i>L>1</i> makes sense.
 200                         </p><p>
 201                         The second definition can also contain spaces at the end, however, so for any
 202                         <i>N=K*L+M</i>, <i>A(N)</i> cannot be larger than <i>A(K)+5+2*L+M</i>.
 203                         </p><p>
 204                         Not surprisingly, this leads to exactly the same <i>L>1+7/(K-2)</i> (as we can
 205                         append the <i>M</i> spaces in the last definition, no matter if we use 1 or
 206                         2 definitions).
 207                         </p><p>
 208                         However, that means that as soon as <i>N>=18</i>, we should use two definitions,
 209                         prior to that, it makes no sense.
 210                         </p><p>
 211                         So for <i>N<18</i>, <i>A(N)=5+N</i>.
 212                         </p><p>
 213                         But what <i>K</i> should one choose, i.e. how many spaces in the first definition?
 214                         In other words, what is <i>A(N)</i> given that we use two definitions?
 215                         </p><p>
 216                         That will have to wait for another midnight.  Just a teaser: <i>A(80)=36</i>.  Oh,
 217                         and with 80 characters, you can define a string of 9900 spaces...
 218                         </p>
 219                         <h6>Monday, 26th of January, Anno Domini MMIX, at the hour of the Dog</h6>
 220                         <a name=1232997290>
 221                         <h2>Valgrind takes a loooong time</h2>
 222
 223                         <p>
 224                         </p><p>
 225                         Yesterday, I started a run on a fast machine, and it took roughly 5.5
 226                         hours by the machine's clock.
 227                         </p><p>
 228                         And of course, I redirected stdout only... *sigh*
 229                         </p><p>
 230                         Which triggered a Google search how to force redirection of all the output
 231                         in the test scripts to a file and the terminal at the same time.
 232                         </p><p>
 233                         It seems as if that is not easily done.  I tried
 234                         <center><table
 235                                                         border=1 bgcolor=black>
 236                                                 <tr><td bgcolor=lightblue colspan=3>
 237                                 <pre>                                                                                </pre>
 238                         </td></tr>
 239                         <tr><td>
 240                                 <table cellspacing=5 border=0
 241                                          style="color:white;">
 242                                 <tr><td>
 243                                         <pre>
 244 exec >(tee out) 2>&1
 245 </pre>
 246                                                         </td></tr>
 247                                                         </table>
 248                                                 </td></tr>
 249                                                 </table></center>
 250                         </p><p>
 251                         but that did not work: it mumbled something about invalid file handles or some
 252                         such.
 253                         </p><p>
 254                         The only solution I found was:
 255                         <center><table
 256                                                         border=1 bgcolor=black>
 257                                                 <tr><td bgcolor=lightblue colspan=3>
 258                                 <pre>                                                                                </pre>
 259                         </td></tr>
 260                         <tr><td>
 261                                 <table cellspacing=5 border=0
 262                                          style="color:white;">
 263                                 <tr><td>
 264                                         <pre>
 265 mkpipe pipe
 266 tee out < pipe &
 267 exec > pipe 2>&1
 268 </pre>
 269                                                         </td></tr>
 270                                                         </table>
 271                                                 </td></tr>
 272                                                 </table></center>
 273                         </p><p>
 274                         That is a problem for parallel execution, though, so I am still looking for a
 275                         better way to do it.
 276                         </p><p>
 277                         Once I have the output, it is relatively easy to analyze it, as I already
 278                         made a script which disects the output into valgrind output and the test
 279                         case it came from, then groups by common valgrind output and shows the
 280                         result to the user.
 281                         </p>
 282                         <h6>Monday, 26th of January, Anno Domini MMIX, at the hour of the Rat</h6>
 283                         <a name=1232927812>
 284                         <h2>A day full of rebase... and a little valgrind</h2>
 285
 286                         <p>
 287                         </p><p>
 288                         I think that I am progressing nicely with my rebase -p work, so much so
 289                         that I will soon be able to use it myself to work on topic branches <u>and</u>
 290                         rebase all the time without much hassle.
 291                         </p><p>
 292                         In other words, I would like to be able to rebase all my topic branches
 293                         to Junio's <i>next</i> branch whenever that has new commits.  With a single
 294                         rebase.
 295                         </p><p>
 296                         And finally, I got the idea of the thing Stephen implemented for dropped
 297                         commits; however, I am quite sure I do not like it.
 298                         </p><p>
 299                         So what are "dropped" commits?
 300                         </p><p>
 301                         When you rebase, chances are that the upstream already has applied at
 302                         least some of your patches.  So we filter those out with <i>--cherry-pick</i>.
 303                         Stephen calls those "dropped" commits.
 304                         </p><p>
 305                         Then he goes on to reinvent the "$REWRITTEN" system: a directory containing
 306                         the mappings of old commit names to new commit names.  That is easily fixed.
 307                         </p><p>
 308                         But worse, he substitutes the dropped commits with their <u>parents</u>, instead
 309                         of substituting them with the corresponding commits in upstream.
 310                         </p><p>
 311                         I guess this will be a medium-sized fight on the mailing list, depending
 312                         how much energy Stephen wants to put in to defend his strategy.
 313                         </p><p>
 314                         Anyway, I finally got to a point where only three of the tests are failing,
 315                         t3404, t3410 and t3412.  Somewhat disappointing is t3404, as its name pretends
 316                         not to exercize -p at all.  Oh well, I guess I'll see what is broken tomorrow.
 317                         </p><p>
 318                         Another part of the day was dedicated to the Valgrind patch series, which
 319                         should give us yet another level of code quality.
 320                         </p><p>
 321                         After having confused myself with several diverging/obsolete branches, I did
 322                         indeed finally manage to send that patch series off.  Woohoo.
 323                         </p>
 324                         <h6>Sunday, 25th of January, Anno Domini MMIX, at the hour of the Goat</h6>
 325                         <a name=1232888842>
 326                         <h2>Regular diff with word coloring (as opposed to word diff)</h2>
 327
 328                         <p>
 329                         </p><p>
 330                         You know, if I were a bit faster with everything I do, I could do so much more!
 331                         </p><p>
 332                         For example, Junio's idea that you could keep showing a regular diff, only
 333                         coloring the words that have been removed/deleted.
 334                         </p><p>
 335                         Just imagine looking at the diff of a long line in LaTeX source code.  It
 336                         should be much nicer to the eye to see the complete removed/added sentences
 337                         instead of one sentence with colored words in between, disrupting your read
 338                         flow.
 339                         </p><p>
 340                         Compare these two versions:
 341                         </p><p>
 342                         Regular diff with colored words:
 343                         <blockquote><tt>
 344                         -This sentence has a <font color=red>tyop</font> in it.<br>
 345                         +This sentence has a <font color=green>typo</font> in it.<br>
 346                         </tt></blockquote>
 347                         </p><p>
 348                         Word diff:
 349                         <blockquote><tt>
 350                         This sentence has a <font color=red>tyop</font><font color=green>typo</font> in it.<br>
 351                         </tt></blockquote>
 352                         </p><p>
 353                         And it should not be hard to do at all!
 354                         </p><p>
 355                         In <i>diff_words_show()</i>, we basically get the minus lines as
 356                         <i>diff_words->minus</i> and the plus lines as <i>diff_words->plus</i>.  The
 357                         function then prepares the word lists and calls the xdiff engine to do all the
 358                         hard work, analyzing the result from xdiff and printing the lines in
 359                         <i>fn_out_diff_words_aux()</i>.
 360                         </p><p>
 361                         So all that would have to be changed would be to <u>record</u> the positions
 362                         of the removed/added words instead of outputting them, and at the end printing
 363                         the minus/plus buffers using the recorded information to color the words.
 364                         </p><p>
 365                         This would involve
 366                         </p><p>
 367                         <ul>
 368                         <li>adding two new members holding the offsets in the <i>diff_words</i>
 369                         struct,
 370                         <li>having a special handling for that mode in
 371                         <i>fn_out_diff_words_aux()</i> that appends the offsets and
 372                         returns,
 373                         <li>adding a function <i>show_lines_with_colored_words()</i> that
 374                         outputs a buffer with a given prefix ('-' or '+') and coloring the words at
 375                         given offsets with a given color,
 376                         <li>modify <i>diff_words_show()</i> to call that function for the "special
 377                         case: only removal" and at the end of the function, and
 378                         <li> disabling the <i>fwrite()</i> at the end of <i>diff_words_show()</i> for that
 379                         mode.
 380                         </ul>
 381                         </p><p>
 382                         Of course, the hardest part is to find a nice user interface for that.  Maybe
 383                         <i>--colored-words</i>? &#x263a;
 384                         </p>
 385                         <h6>Saturday, 24th of January, Anno Domini MMIX, at the hour of the Pig</h6>
 386                         <a name=1232828715>
 387                         <h2>Ideas for a major revamp of the <i>--preserve-merges</i> handling in <i>git rebase</i></h2>
 388
 389                         <p>
 390                         </p><p>
 391                         As probably everybody agrees, the code to preserve merges is a big mess
 392                         right now.
 393                         </p><p>
 394                         Worse, the whole concept of "pick <merge-sha1>" just does not fly well.
 395                         </p><p>
 396                         So I started a <u>major</u> cleanup, which happens to reduce the code very
 397                         nicely so far.
 398                         </p><p>
 399                         It will take a few days to flesh out, I guess, but these are the major
 400                         ideas of my work:
 401                         </p><p>
 402                         <b>pick $sha1</b><br>
 403                         <blockquote>will only work on non-merges in the future.</blockquote>
 404                         <b>merge $sha1 [$sha1...] was $sha1 Merge ...</b><br>
 405                         <blockquote>will merge the given list of commits into the current HEAD, for
 406                                 the user's reference and to keep up-to-date what was rewritten,
 407                                 the original merge is shown after the keyword "was" (which is not
 408                                 a valid SHA-1, luckily).</blockquote>
 409                         <b>goto $sha1</b><br>
 410                         <blockquote>will reset the HEAD to the given commit.</blockquote>
 411                         <b>$sha1'</b><br>
 412                         <blockquote>for merge and goto, if a $sha1 ends in a single quote, the
 413                                 rewritten commit is substituted (if there is one).</blockquote>
 414                         </p><p>
 415                         Example:
 416                         </p><p>
 417 <pre>
 418 A - B - - - E
 419   \       /
 420     C - D
 421 </pre>
 422                         </p><p>
 423                         could yield this TODO script:
 424                         </p><p>
 425 <pre>
 426         pick A
 427         pick C
 428         pick D
 429         goto A'
 430         pick B
 431         merge D' was E
 432 </pre>
 433                         </p><p>
 434                         This should lead to a much more intuitive user experience.
 435                         </p><p>
 436                         I am very sorry if somebody actually scripted <i>rebase -i -p</i> (by setting
 437                         GIT_EDITOR with a script), but I am very certain that this cleanup is
 438                         absolutely necessary to make <i>rebase -i -p</i> useful.
 439                         </p>
 440                         <h6>Saturday, 24th of January, Anno Domini MMIX, at the hour of the Dragon</h6>
 441                         <a name=1232778113>
 442                         <h2>Thoughts about <i>interactive rebase</i></h2>
 443
 444                         <p>
 445                         </p><p>
 446                         Somebody mentioned that my <i>my-next</i> branch is a mess, as it mixes all
 447                         kinds of topics.
 448                         </p><p>
 449                         That is undeniably true, however, there is a good reason that I do not
 450                         have a lot of topic branches: I work on more than just one computer.
 451                         </p><p>
 452                         To make sure that I do not lose a commit by mistake, I always <i>rebase -i</i>
 453                         the <i>my-next</i> branch of the computer I happen to work on on top of the
 454                         <i>my-next</i> branch I fetch from <a href=http://repo.or.cz>repo.or.cz</a>.
 455                         </p><p>
 456                         To rebase a lot of topic branches at the same time seems a bit complicated.
 457                         But that is actually what the <i>-p</i> option (preserve merges) is all about.
 458                         </p><p>
 459                         The only problem is that the code for <i>rebase -i -p</i> has been messed up
 460                         recently, quite successfully, I might add.
 461                         </p><p>
 462                         Worse, some people are pushing for a completely and total unintuitive syntax.
 463                         </p><p>
 464                         So maybe I will start to work on <i>-p</i> again, for my own use (I should learn
 465                         to heed the principle more: work on things I can use myself).
 466                         </p><p>
 467                         My current idea is to implement a "goto" statement that will jump to another
 468                         commit.  To make it easily usable, I will add the semantics that "goto" will
 469                         always try to go to the <u>rewritten</u> version of the given commit; if the user
 470                         wanted to have the original commit, she has to paste the unabbreviated commit
 471                         name.
 472                         </p><p>
 473                         The more I think about it, the more I actually like this idea &#x263a;
 474                         </p><p>
 475                         Of course, working on this little project means that I will have to cope with
 476                         that ugly code again.  *urgh*
 477                         </p>
 478                         <h6>Friday, 23rd of January, Anno Domini MMIX, at the hour of the Pig</h6>
 479                         <a name=1232745071>
 480                         <h2>Git Logos</h2>
 481
 482                         <p>
 483                         </p><p>
 484                         The other day, when I did not exactly have too much time on my hands, but
 485                         definitely too much motivation, I played around creating several logos.
 486                         </p><p>
 487                         An ambigram (if you turn it 180 degrees around the appropriate axis, it looks
 488                         exactly the same as unrotated):
 489                         </p><p>
 490                         <center>
 491                                 <table border=0>
 492                                         <tr>
 493                                                 <td align=center>
 494                                                         <embed type="image/svg+xml"
 495                                                                 src="dscho.git?a=blob_plain;hb=aaa9edafbe6ca5349ad7b36848fb294e5f4fc529;f=git-ambigram.svg" width=317 />
 496                                                 </td>
 497                                         </tr>
 498                                         <tr>
 499                                                 <td align=center>
 500                                                         <a href=dscho.git?a=blob_plain;hb=aaa9edafbe6ca5349ad7b36848fb294e5f4fc529;f=git-ambigram.svg>git-ambigram.svg</a>
 501                                                 </td>
 502                                         </tr>
 503                                 </table>
 504                         </center>
 505                         </p><p>
 506                         A play on gitk:
 507                         </p><p>
 508                         <center>
 509                                 <table border=0>
 510                                         <tr>
 511                                                 <td align=center>
 512                                                         <embed type="image/svg+xml"
 513                                                                 src="dscho.git?a=blob_plain;hb=aaa9edafbe6ca5349ad7b36848fb294e5f4fc529;f=git-gitk-logo.svg" width=325 />
 514                                                 </td>
 515                                         </tr>
 516                                         <tr>
 517                                                 <td align=center>
 518                                                         <a href=dscho.git?a=blob_plain;hb=aaa9edafbe6ca5349ad7b36848fb294e5f4fc529;f=git-gitk-logo.svg>git-gitk-logo.svg</a>
 519                                                 </td>
 520                                         </tr>
 521                                 </table>
 522                         </center>
 523                         </p><p>
 524                         A play on the test you have to go through before getting new glasses:
 525                         </p><p>
 526                         <center>
 527                                 <table border=0>
 528                                         <tr>
 529                                                 <td align=center>
 530                                                         <embed type="image/svg+xml"
 531                                                                 src="dscho.git?a=blob_plain;hb=aaa9edafbe6ca5349ad7b36848fb294e5f4fc529;f=git-visual-test.svg" width=325 />
 532                                                 </td>
 533                                         </tr>
 534                                         <tr>
 535                                                 <td align=center>
 536                                                         <a href=dscho.git?a=blob_plain;hb=aaa9edafbe6ca5349ad7b36848fb294e5f4fc529;f=git-visual-test.svg>git-visual-test.svg</a>
 537                                                 </td>
 538                                         </tr>
 539                                 </table>
 540                         </center>
 541                         </p><p>
 542                         This is Henrik Nyh's logo (converted to .svg by yours truly):
 543                         </p><p>
 544                         <center>
 545                                 <table border=0>
 546                                         <tr>
 547                                                 <td align=center>
 548                                                         <embed type="image/svg+xml"
 549                                                                 src="dscho.git?a=blob_plain;hb=aaa9edafbe6ca5349ad7b36848fb294e5f4fc529;f=gitlogo.svg" width=165 />
 550                                                 </td>
 551                                         </tr>
 552                                         <tr>
 553                                                 <td align=center>
 554                                                         <a href=dscho.git?a=blob_plain;hb=aaa9edafbe6ca5349ad7b36848fb294e5f4fc529;f=gitlogo.svg>gitlogo.svg</a>
 555                                                 </td>
 556                                         </tr>
 557                                 </table>
 558                         </center>
 559                         </p><p>
 560                         And of course, the original logo...
 561                         </p><p>
 562                         <center>
 563                                 <table border=0>
 564                                         <tr>
 565                                                 <td align=center>
 566                                                         <embed type="image/svg+xml"
 567                                                                 src="dscho.git?a=blob_plain;hb=aaa9edafbe6ca5349ad7b36848fb294e5f4fc529;f=original-git-logo.svg" width=165 />
 568                                                 </td>
 569                                         </tr>
 570                                         <tr>
 571                                                 <td align=center>
 572                                                         <a href=dscho.git?a=blob_plain;hb=aaa9edafbe6ca5349ad7b36848fb294e5f4fc529;f=original-git-logo.svg>original-git-logo.svg</a>
 573                                                 </td>
 574                                         </tr>
 575                                 </table>
 576                         </center>
 577                         </p><p>
 578                         Maybe some of you have fun with them...
 579                         </p>
 580                         <h6>Friday, 23rd of January, Anno Domini MMIX, at the hour of the Pig</h6>
 581                         <a name=1232742582>
 582                         <h2>How to deal with files that are not source code when merging</h2>
 583
 584                         <p>
 585                         </p><p>
 586                         Last week, one of the mentors of last year's <a href=http://code.google.com/soc>
 587                         Summer of Code</a> mentioned the idea that merge strategies are in dear need
 588                         for file types other than source code.
 589                         </p><p>
 590                         I think this idea is awesome, even if I cannot bring myself to believe that
 591                         any of the file types would make a good Summer of Code project: either they
 592                         are too complicated (think raster images such as .png or even .jpg), or they
 593                         are too straight-forward (think LaTeX, where all that is needed is a good
 594                         graphical user interface to inspect the three versions: <i>ours</i>, <i>baseline</i>
 595                         and <i>theirs</i>).
 596                         </p><p>
 597                         The LaTeX idea would be a good project for me to mentor, though: I have a
 598                         pretty clear idea how it should be done; I just lack the time (and motivation)
 599                         to do it myself.
 600                         </p><p>
 601                         As for OpenOffice text documents, vector graphics (such as .svg), or more
 602                         specific data such as spreadsheets, I think that all of these are really
 603                         difficult: the problem is not so much the implementation (i.e. the programming
 604                         part of it), but the design.
 605                         </p><p>
 606                         This design should involve much more than a Summer of Code project is about:
 607                         you would need to survey users' expectations, and at least the mentor -- if
 608                         not the student -- would need to be an expert in usability questions, which
 609                         is rather unlikely in the realm of Open Source.
 610                         </p><p>
 611                         Maybe this is the missing part in Open Source: we have many brilliant
 612                         programmers, but next to nobody with a good idea how to design intuitive
 613                         user interfaces.
 614                         </p><p>
 615                         That might be related to the fact that brilliant software engineers, as they
 616                         can be found in Open Source, are not exactly known for their social skills,
 617                         a human trait that seems to be a very important prerequisite for designing
 618                         intuitive user interfaces.
 619                         </p><p>
 620                         Well, I have <a href=http://git.or.cz/gitwiki/SoC2009Ideas#head-6188833471f79f277e162ef9fbe1592aa10b5f6c>
 621                         added</a> the proposal to Git's Summer of Code idea page on the Git Wiki; We will
 622                         see what comes out of it.
 623                         </p>
 624                 </div>
 625         </body>
 626 </html>