?  search:
summary | log | graphiclog1 | graphiclog2 | commit | commitdiff | tree | refs | edit | fork
blame | history | raw | HEAD
Housekeeping on Monday, 26th of January, Anno Domini MMIX, at the hour of the Dog
[git/dscho.git] / index.html
blob55b74e6dc3ff39b39a6b203511bb78a1eb798bc4
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=#1232997290>26 Jan 2009 Valgrind takes a loooong time</a>
16 <li><a href=#1232927812>26 Jan 2009 A day full of rebase... and a little valgrind</a>
17 <li><a href=#1232888842>25 Jan 2009 Regular diff with word coloring (as opposed to word diff)</a>
18 <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>
19 <li><a href=#1232778113>24 Jan 2009 Thoughts about <i>interactive rebase</i></a>
20 <li><a href=#1232745071>23 Jan 2009 Git Logos</a>
21 <li><a href=#1232742582>23 Jan 2009 How to deal with files that are not source code when merging</a>
22 <li><a href=#1232626236>22 Jan 2009 The UGFWIINI contest</a>
23 <li><a href=#1232611542>22 Jan 2009 Top-posting</a>
24 <li><a href=#1232607201>22 Jan 2009 Sverre's hat</a>
25 </ul></p>
26 <a href=dscho.git?a=blob_plain;hb=8a514068173cf759e723dfaf1649800f62263c22;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>Monday, 26th of January, Anno Domini MMIX, at the hour of the Dog</h6>
90 <a name=1232997290>
91 <h2>Valgrind takes a loooong time</h2>
92
93 <p>
94 </p><p>
95 Yesterday, I started a run on a fast machine, and it took roughly 5.5
96 hours by the machine's clock.
97 </p><p>
98 And of course, I redirected stdout only... *sigh*
99 </p><p>
100 Which triggered a Google search how to force redirection of all the output
101 in the test scripts to a file and the terminal at the same time.
102 </p><p>
103 It seems as if that is not easily done. I tried
104 <center><table
105 border=1 bgcolor=black>
106 <tr><td bgcolor=lightblue colspan=3>
107 &nbsp;
108 </td></tr>
109 <tr><td>
110 <table cellspacing=5 border=0
111 style="color:white;">
112 <tr><td>
113 <pre>
114 exec >(tee out) 2>&1 </pre>
115 </td></tr>
116 </table>
117 </td></tr>
118 </table></center>
119 </p><p>
120 but that did not work: it mumbled something about invalid file handles or some
121 such.
122 </p><p>
123 The only solution I found was:
124 <center><table
125 border=1 bgcolor=black>
126 <tr><td bgcolor=lightblue colspan=3>
127 &nbsp;
128 </td></tr>
129 <tr><td>
130 <table cellspacing=5 border=0
131 style="color:white;">
132 <tr><td>
133 <pre>
134 mkpipe pipe
135 tee out < pipe &
136 exec > pipe 2>&1 </pre>
137 </td></tr>
138 </table>
139 </td></tr>
140 </table></center>
141 </p><p>
142 That is a problem for parallel execution, though, so I am still looking for a
143 better way to do it.
144 </p><p>
145 Once I have the output, it is relatively easy to analyze it, as I already
146 made a script which disects the output into valgrind output and the test
147 case it came from, then groups by common valgrind output and shows the
148 result to the user.
149 </p>
150 <h6>Monday, 26th of January, Anno Domini MMIX, at the hour of the Rat</h6>
151 <a name=1232927812>
152 <h2>A day full of rebase... and a little valgrind</h2>
153
154 <p>
155 </p><p>
156 I think that I am progressing nicely with my rebase -p work, so much so
157 that I will soon be able to use it myself to work on topic branches <u>and</u>
158 rebase all the time without much hassle.
159 </p><p>
160 In other words, I would like to be able to rebase all my topic branches
161 to Junio's <i>next</i> branch whenever that has new commits. With a single
162 rebase.
163 </p><p>
164 And finally, I got the idea of the thing Stephen implemented for dropped
165 commits; however, I am quite sure I do not like it.
166 </p><p>
167 So what are "dropped" commits?
168 </p><p>
169 When you rebase, chances are that the upstream already has applied at
170 least some of your patches. So we filter those out with <i>--cherry-pick</i>.
171 Stephen calls those "dropped" commits.
172 </p><p>
173 Then he goes on to reinvent the "$REWRITTEN" system: a directory containing
174 the mappings of old commit names to new commit names. That is easily fixed.
175 </p><p>
176 But worse, he substitutes the dropped commits with their <u>parents</u>, instead
177 of substituting them with the corresponding commits in upstream.
178 </p><p>
179 I guess this will be a medium-sized fight on the mailing list, depending
180 how much energy Stephen wants to put in to defend his strategy.
181 </p><p>
182 Anyway, I finally got to a point where only three of the tests are failing,
183 t3404, t3410 and t3412. Somewhat disappointing is t3404, as its name pretends
184 not to exercize -p at all. Oh well, I guess I'll see what is broken tomorrow.
185 </p><p>
186 Another part of the day was dedicated to the Valgrind patch series, which
187 should give us yet another level of code quality.
188 </p><p>
189 After having confused myself with several diverging/obsolete branches, I did
190 indeed finally manage to send that patch series off. Woohoo.
191 </p>
192 <h6>Sunday, 25th of January, Anno Domini MMIX, at the hour of the Goat</h6>
193 <a name=1232888842>
194 <h2>Regular diff with word coloring (as opposed to word diff)</h2>
195
196 <p>
197 </p><p>
198 You know, if I were a bit faster with everything I do, I could do so much more!
199 </p><p>
200 For example, Junio's idea that you could keep showing a regular diff, only
201 coloring the words that have been removed/deleted.
202 </p><p>
203 Just imagine looking at the diff of a long line in LaTeX source code. It
204 should be much nicer to the eye to see the complete removed/added sentences
205 instead of one sentence with colored words in between, disrupting your read
206 flow.
207 </p><p>
208 Compare these two versions:
209 </p><p>
210 Regular diff with colored words:
211 <blockquote><tt>
212 -This sentence has a <font color=red>tyop</font> in it.<br>
213 +This sentence has a <font color=green>typo</font> in it.<br>
214 </tt></blockquote>
215 </p><p>
216 Word diff:
217 <blockquote><tt>
218 This sentence has a <font color=red>tyop</font><font color=green>typo</font> in it.<br>
219 </tt></blockquote>
220 </p><p>
221 And it should not be hard to do at all!
222 </p><p>
223 In <i>diff&#95;words&#95;show()</i>, we basically get the minus lines as
224 <i>diff&#95;words->minus</i> and the plus lines as <i>diff&#95;words->plus</i>. The
225 function then prepares the word lists and calls the xdiff engine to do all the
226 hard work, analyzing the result from xdiff and printing the lines in
227 <i>fn&#95;out&#95;diff&#95;words&#95;aux()</i>.
228 </p><p>
229 So all that would have to be changed would be to <u>record</u> the positions
230 of the removed/added words instead of outputting them, and at the end printing
231 the minus/plus buffers using the recorded information to color the words.
232 </p><p>
233 This would involve
234 </p><p>
235 <ul>
236 <li>adding two new members holding the offsets in the <i>diff&#95;words</i>
237 struct,
238 <li>having a special handling for that mode in
239 <i>fn&#95;out&#95;diff&#95;words&#95;aux()</i> that appends the offsets and
240 returns,
241 <li>adding a function <i>show&#95;lines&#95;with&#95;colored&#95;words()</i> that
242 outputs a buffer with a given prefix ('-' or '+') and coloring the words at
243 given offsets with a given color,
244 <li>modify <i>diff&#95;words&#95;show()</i> to call that function for the "special
245 case: only removal" and at the end of the function, and
246 <li> disabling the <i>fwrite()</i> at the end of <i>diff<u>words</u>show()</i> for that
247 mode.
248 </ul>
249 </p><p>
250 Of course, the hardest part is to find a nice user interface for that. Maybe
251 <i>--colored-words</i>? &#x263a;
252 </p>
253 <h6>Saturday, 24th of January, Anno Domini MMIX, at the hour of the Pig</h6>
254 <a name=1232828715>
255 <h2>Ideas for a major revamp of the <i>--preserve-merges</i> handling in <i>git rebase</i></h2>
256
257 <p>
258 </p><p>
259 As probably everybody agrees, the code to preserve merges is a big mess
260 right now.
261 </p><p>
262 Worse, the whole concept of "pick <merge-sha1>" just does not fly well.
263 </p><p>
264 So I started a <u>major</u> cleanup, which happens to reduce the code very
265 nicely so far.
266 </p><p>
267 It will take a few days to flesh out, I guess, but these are the major
268 ideas of my work:
269 </p><p>
270 <b>pick $sha1</b><br>
271 <blockquote>will only work on non-merges in the future.</blockquote>
272 <b>merge $sha1 [$sha1...] was $sha1 Merge ...</b><br>
273 <blockquote>will merge the given list of commits into the current HEAD, for
274 the user's reference and to keep up-to-date what was rewritten,
275 the original merge is shown after the keyword "was" (which is not
276 a valid SHA-1, luckily).</blockquote>
277 <b>goto $sha1</b><br>
278 <blockquote>will reset the HEAD to the given commit.</blockquote>
279 <b>$sha1'</b><br>
280 <blockquote>for merge and goto, if a $sha1 ends in a single quote, the
281 rewritten commit is substituted (if there is one).</blockquote>
282 </p><p>
283 Example:
284 </p><p>
285 <pre>
286 A - B - - - E
287 \ /
288 C - D
289 </pre>
290 </p><p>
291 could yield this TODO script:
292 </p><p>
293 <pre>
294 pick A
295 pick C
296 pick D
297 goto A'
298 pick B
299 merge D' was E
300 </pre>
301 </p><p>
302 This should lead to a much more intuitive user experience.
303 </p><p>
304 I am very sorry if somebody actually scripted <i>rebase -i -p</i> (by setting
305 GIT_EDITOR with a script), but I am very certain that this cleanup is
306 absolutely necessary to make <i>rebase -i -p</i> useful.
307 </p>
308 <h6>Saturday, 24th of January, Anno Domini MMIX, at the hour of the Dragon</h6>
309 <a name=1232778113>
310 <h2>Thoughts about <i>interactive rebase</i></h2>
311
312 <p>
313 </p><p>
314 Somebody mentioned that my <i>my-next</i> branch is a mess, as it mixes all
315 kinds of topics.
316 </p><p>
317 That is undeniably true, however, there is a good reason that I do not
318 have a lot of topic branches: I work on more than just one computer.
319 </p><p>
320 To make sure that I do not lose a commit by mistake, I always <i>rebase -i</i>
321 the <i>my-next</i> branch of the computer I happen to work on on top of the
322 <i>my-next</i> branch I fetch from <a href=http://repo.or.cz>repo.or.cz</a>.
323 </p><p>
324 To rebase a lot of topic branches at the same time seems a bit complicated.
325 But that is actually what the <i>-p</i> option (preserve merges) is all about.
326 </p><p>
327 The only problem is that the code for <i>rebase -i -p</i> has been messed up
328 recently, quite successfully, I might add.
329 </p><p>
330 Worse, some people are pushing for a completely and total unintuitive syntax.
331 </p><p>
332 So maybe I will start to work on <i>-p</i> again, for my own use (I should learn
333 to heed the principle more: work on things I can use myself).
334 </p><p>
335 My current idea is to implement a "goto" statement that will jump to another
336 commit. To make it easily usable, I will add the semantics that "goto" will
337 always try to go to the <u>rewritten</u> version of the given commit; if the user
338 wanted to have the original commit, she has to paste the unabbreviated commit
339 name.
340 </p><p>
341 The more I think about it, the more I actually like this idea &#x263a;
342 </p><p>
343 Of course, working on this little project means that I will have to cope with
344 that ugly code again. *urgh*
345 </p>
346 <h6>Friday, 23rd of January, Anno Domini MMIX, at the hour of the Pig</h6>
347 <a name=1232745071>
348 <h2>Git Logos</h2>
349
350 <p>
351 </p><p>
352 The other day, when I did not exactly have too much time on my hands, but
353 definitely too much motivation, I played around creating several logos.
354 </p><p>
355 An ambigram (if you turn it 180 degrees around the appropriate axis, it looks
356 exactly the same as unrotated):
357 </p><p>
358 <center>
359 <table border=0>
360 <tr>
361 <td align=center>
362 <embed type="image/svg+xml"
363 src="3131BLOBPLAIN;hb=aaa9edafbe6ca5349ad7b36848fb294e5f4fc529;f=git-ambigram.svg" width=317 />
364 </td>
365 </tr>
366 <tr>
367 <td align=center>
368 <a href=3131BLOBPLAIN;hb=aaa9edafbe6ca5349ad7b36848fb294e5f4fc529;f=git-ambigram.svg>git-ambigram.svg</a>
369 </td>
370 </tr>
371 </table>
372 </center>
373 </p><p>
374 A play on gitk:
375 </p><p>
376 <center>
377 <table border=0>
378 <tr>
379 <td align=center>
380 <embed type="image/svg+xml"
381 src="3150BLOBPLAIN;hb=aaa9edafbe6ca5349ad7b36848fb294e5f4fc529;f=git-gitk-logo.svg" width=325 />
382 </td>
383 </tr>
384 <tr>
385 <td align=center>
386 <a href=3150BLOBPLAIN;hb=aaa9edafbe6ca5349ad7b36848fb294e5f4fc529;f=git-gitk-logo.svg>git-gitk-logo.svg</a>
387 </td>
388 </tr>
389 </table>
390 </center>
391 </p><p>
392 A play on the test you have to go through before getting new glasses:
393 </p><p>
394 <center>
395 <table border=0>
396 <tr>
397 <td align=center>
398 <embed type="image/svg+xml"
399 src="3169BLOBPLAIN;hb=aaa9edafbe6ca5349ad7b36848fb294e5f4fc529;f=git-visual-test.svg" width=325 />
400 </td>
401 </tr>
402 <tr>
403 <td align=center>
404 <a href=3169BLOBPLAIN;hb=aaa9edafbe6ca5349ad7b36848fb294e5f4fc529;f=git-visual-test.svg>git-visual-test.svg</a>
405 </td>
406 </tr>
407 </table>
408 </center>
409 </p><p>
410 This is Henrik Nyh's logo (converted to .svg by yours truly):
411 </p><p>
412 <center>
413 <table border=0>
414 <tr>
415 <td align=center>
416 <embed type="image/svg+xml"
417 src="3188BLOBPLAIN;hb=aaa9edafbe6ca5349ad7b36848fb294e5f4fc529;f=gitlogo.svg" width=165 />
418 </td>
419 </tr>
420 <tr>
421 <td align=center>
422 <a href=3188BLOBPLAIN;hb=aaa9edafbe6ca5349ad7b36848fb294e5f4fc529;f=gitlogo.svg>gitlogo.svg</a>
423 </td>
424 </tr>
425 </table>
426 </center>
427 </p><p>
428 And of course, the original logo...
429 </p><p>
430 <center>
431 <table border=0>
432 <tr>
433 <td align=center>
434 <embed type="image/svg+xml"
435 src="3207BLOBPLAIN;hb=aaa9edafbe6ca5349ad7b36848fb294e5f4fc529;f=original-git-logo.svg" width=165 />
436 </td>
437 </tr>
438 <tr>
439 <td align=center>
440 <a href=3207BLOBPLAIN;hb=aaa9edafbe6ca5349ad7b36848fb294e5f4fc529;f=original-git-logo.svg>original-git-logo.svg</a>
441 </td>
442 </tr>
443 </table>
444 </center>
445 </p><p>
446 Maybe some of you have fun with them...
447 </p>
448 <h6>Friday, 23rd of January, Anno Domini MMIX, at the hour of the Pig</h6>
449 <a name=1232742582>
450 <h2>How to deal with files that are not source code when merging</h2>
451
452 <p>
453 </p><p>
454 Last week, one of the mentors of last year's <a href=http://code.google.com/soc>
455 Summer of Code</a> mentioned the idea that merge strategies are in dear need
456 for file types other than source code.
457 </p><p>
458 I think this idea is awesome, even if I cannot bring myself to believe that
459 any of the file types would make a good Summer of Code project: either they
460 are too complicated (think raster images such as .png or even .jpg), or they
461 are too straight-forward (think LaTeX, where all that is needed is a good
462 graphical user interface to inspect the three versions: <i>ours</i>, <i>baseline</i>
463 and <i>theirs</i>).
464 </p><p>
465 The LaTeX idea would be a good project for me to mentor, though: I have a
466 pretty clear idea how it should be done; I just lack the time (and motivation)
467 to do it myself.
468 </p><p>
469 As for OpenOffice text documents, vector graphics (such as .svg), or more
470 specific data such as spreadsheets, I think that all of these are really
471 difficult: the problem is not so much the implementation (i.e. the programming
472 part of it), but the design.
473 </p><p>
474 This design should involve much more than a Summer of Code project is about:
475 you would need to survey users' expectations, and at least the mentor -- if
476 not the student -- would need to be an expert in usability questions, which
477 is rather unlikely in the realm of Open Source.
478 </p><p>
479 Maybe this is the missing part in Open Source: we have many brilliant
480 programmers, but next to nobody with a good idea how to design intuitive
481 user interfaces.
482 </p><p>
483 That might be related to the fact that brilliant software engineers, as they
484 can be found in Open Source, are not exactly known for their social skills,
485 a human trait that seems to be a very important prerequisite for designing
486 intuitive user interfaces.
487 </p><p>
488 Well, I have <a href=http://git.or.cz/gitwiki/SoC2009Ideas#head-6188833471f79f277e162ef9fbe1592aa10b5f6c>
489 added</a> the proposal to Git's Summer of Code idea page on the Git Wiki; We will
490 see what comes out of it.
491 </p>
492 <h6>Thursday, 22nd of January, Anno Domini MMIX, at the hour of the Goat</h6>
493 <a name=1232626236>
494 <h2>The UGFWIINI contest</h2>
495
496 <p>
497 </p><p>
498 Just in case somebody finds this blog, here is a challenge. Inspired by my
499 own little hack (this blog), I announce the "Using Git For What It Is Not
500 Intended" contest.
501 </p><p>
502 And it is especially cool, since the acronym sounds cool! You might miss
503 this fact if you do no know that I pronounce the "F" like an "A" so that
504 it sounds cool.
505 </p><p>
506 This will be a running contest; whenever I have 10 valid applications, I
507 will announce a winner on the Git mailing list.
508 </p><p>
509 So, what accounts for a valid application?
510 </p><p>
511 <ul>
512 <li> You must use a Git program (the term is used loosely here, GitWeb is
513 considered a Git program, for example).
514 <li> The program must be intended for something completely different than
515 what you are using it for. E.g. GitWeb -- which was intended to let
516 you browse through the history using your web browser -- is used
517 to serve a blog to the wide world.
518 <li> You must be able to prove that you actually used the Git program to
519 the purpose you claim, preferably in a live demonstration like this
520 one.
521 <li> Nobody and nothing must be harmed in the process (except your
522 laughing muscle, that's okay).
523 </ul>
524 </p><p>
525 So, how does such an abuse look like?
526 </p><p>
527 <ul>
528 <li> ... like this blog.
529 <li> Managing your mail (in maildir format) in a Git repository.
530 <li> Finding duplicate files by
531 <table
532 border=1 bgcolor=black>
533 <tr><td bgcolor=lightblue colspan=3>
534 &nbsp;
535 </td></tr>
536 <tr><td>
537 <table cellspacing=5 border=0
538 style="color:white;">
539 <tr><td>
540 <pre>
541 $ git init
542 $ git add .
543 $ git ls-files --stage | sort -k2 | uniq -d -s7 -w40
544 </pre>
545 </td></tr>
546 </table>
547 </td></tr>
548 </table>
549 <li> Abusing the Git alias mechanism to call scripts defined directly in
550 the config.
551 </ul>
552 </p><p>
553 I am really looking forward to all of your submissions... *chuckles*
554 </p><p>
555 </p>
556 <h6>Thursday, 22nd of January, Anno Domini MMIX, at the hour of the Snake</h6>
557 <a name=1232611542>
558 <h2>Top-posting</h2>
559
560 <p>
561 </p><p>
562 Okay, last post for a while. But this is something that is nagging me
563 tremendously. I should probably just let go, but in my deepest inner self,
564 really close to my heart, I refuse to believe that any human beings could
565 be incapable of certain degrees of reason.
566 </p><p>
567 Take the example of top-posting. Everybody who read a top-posted email
568 knows that you have to scroll down, possibly weeding through tons of
569 pages to find out what the heck the author of the last reply was replying
570 to.
571 </p><p>
572 Never mind that it would take the author of the reply just a couple of
573 seconds to remove all the irrelevant stuff -- as she already knows what
574 is the relevant part, saving minutes, in case of mailing lists hours,
575 easily, to the readers who otherwise would have to discern what is
576 irrelevant and what is relevant first.
577 </p><p>
578 It is a horrible time waste. But of course not for the top-poster.
579 </p><p>
580 The problem is that I frequently run into such people, and when I write
581 them a polite mail, explaining to them that it is impolite to top-post,
582 and why, the answers I get sometimes make me check if the sky is still up
583 and the earth down. Yesterday was an example of such a dubitable
584 pleasure.
585 </p><p>
586 Most funny are the ridiculous attempts by those persons at explaining why
587 top-posting is <i>so</i> much superior to anything else.
588 </p><p>
589 Which is good, because if they were not that funny, they would be pretty sad.
590 </p>
591 <h6>Thursday, 22nd of January, Anno Domini MMIX, at the hour of the Dragon</h6>
592 <a name=1232607201>
593 <h2>Sverre's hat</h2>
594
595 <p>
596 </p><p>
597 The fun part about a blog is that you can talk about less technical stuff.
598 For example, Sverre's hat.
599 </p><p>
600 Let me start a bit earlier, so that you get the context.
601 </p><p>
602 Last year, at the <a href=http://git.or.cz/gitwiki/GitTogether>GitTogether</a>,
603 we had an <a href=http://en.wikipedia.org/wiki/Unconference>unconference style
604 conference</a>, which basically meant that it was our job to decide what
605 we want to talk about.
606 </p><p>
607 It turned out to be pretty hard, because there was so much we wanted to
608 discuss, and because we wanted to get to know each other, and we wanted to
609 do some hacking.
610 </p><p>
611 So to help us decide what subjects, and in which order we wanted to have
612 scheduled, Shawn opened a series on <a href=http://moderator.appspot.com/>
613 Google Moderator</a>, a nifty, yet simple application which allows a group
614 to agree quickly on an agenda.
615 </p><p>
616 It worked quite well; However, that little saboteur displayed his sense of
617 humor so overtly that some entertaining Gitter put the question "Should Sverre
618 wear a hat?" on the agenda.
619 </p><p>
620 Sure enough, the subject got voted up, and eventually, we got Sverre a hat:
621 </p><p>
622 <center><img src=3306BLOBPLAIN;hb=30319f7436828cd15db8a531a0057351d8e361c0;f=sverre-hat.jpg sverre-hat.jpg></center>
623 </p><p>
624 By the way, another thing I like about this blog engine is that there are no
625 comments... Nothing is more annoying than leaving a comment on a blog,
626 forgetting about it for a few months, and then finding somebody answered
627 ages ago.
628 </p><p>
629 Update: Sverre says it was dsymonds idea.
630 </p>
631 </div>
632 </body>
633 </html>
Dscho's miscellaneous git branches