?  search:
summary | log | graphiclog1 | graphiclog2 | commit | commitdiff | tree | refs | edit | fork
blame | history | raw | HEAD
Housekeeping on Thursday, 29th of January, Anno Domini MMIX, at the hour of the Buffalo
[git/dscho.git] / index.html
blob6740987654db19eb0e0fb3074bf4d630d01a5642
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=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 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=#1233154567>28 Jan 2009 Splitting topic branches</a>
16 <li><a href=#1233102919>28 Jan 2009 Showing off that you're an Alpine user ... priceless!</a>
17 <li><a href=#1233101919>28 Jan 2009 Progress with the interactive rebase preserving merges</a>
18 <li><a href=#1233099894>28 Jan 2009 Another midnight riddle?</a>
19 <li><a href=#1233022809>27 Jan 2009 Fun with calculus after midnight</a>
20 <li><a href=#1232997290>26 Jan 2009 Valgrind takes a loooong time</a>
21 <li><a href=#1232927812>26 Jan 2009 A day full of rebase... and a little valgrind</a>
22 <li><a href=#1232888842>25 Jan 2009 Regular diff with word coloring (as opposed to word diff)</a>
23 <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>
24 <li><a href=#1232778113>24 Jan 2009 Thoughts about <i>interactive rebase</i></a>
25 </ul></p>
26 <a href=dscho.git?a=blob_plain;hb=a910b3bb049f5fa34908772ab008a90223a598ac;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 Monkey</h6>
90 <a name=1233154567>
91 <h2>Splitting topic branches</h2>
92
93 <p>
94 </p><p>
95 One might be put off easily by the overarching use of buzzwords in the
96 description of how <i>Darcs</i> works. I, for one, do not expect an intelligent
97 author when I read <i>Theory of patches</i> and <i>based on quantum physics</i>.
98 </p><p>
99 The true story, however, is much simpler, and is actually not that dumb:
100 Let's call two commits "conflicting" when they contain at least one
101 overlapping change.
102 </p><p>
103 The idea is now: Given a list of commits (not a set, as the order is important),
104 to sort them into smaller lists such that conflicting commits are in the
105 sublists ("topic branches") and the sublists are minimal, i.e. no two
106 non-conflicting commits are in the same sublist.
107 </p><p>
108 The idea has flaws, of course, as you can have a patch changing the code,
109 and another changing the documentation, but splitting a list of commits
110 in that way is a first step to sort out my <i>my-next</i> mess, where I have
111 a linear perl of not-necessarily-dependent commits.
112 </p><p>
113 And actually, my whole rebase revamp aimed at the clean-up for my own
114 <i>my-next</i> branch, so I am currently writing a script that can be used
115 as a GIT_EDITOR for git-rebase which implements the Darcs algorithm. Kind of:
116 the result is not implicit, but explicit and can be fixed up later.
117 </p>
118 <h6>Wednesday, 28th of January, Anno Domini MMIX, at the hour of the Buffalo</h6>
119 <a name=1233102919>
120 <h2>Showing off that you're an Alpine user ... priceless!</h2>
121
122 <p>
123 </p><p>
124 So I was in a hurry to send the patches, and sent all the patches as replies
125 to the cover-letter, and therefore typed in <i>rnyn</i> all the time, which is the
126 mantra I need to say to Alpine for <i>Reply</i>, ... include quoted message?
127 <i>No</i>, ... reply to all recipients? <i>Yes</i>, ... use first role?
128 <i>No, use default role</i>.
129 </p><p>
130 That was pretty embarassing, as it shows everybody that I still do not trust
131 <i>send-email</i>, and rather paste every single patch by hand. Which is rather
132 annoying.
133 </p><p>
134 So I started using format-patch today, to output directly to Alpine's
135 <i>postponed-msgs</i> folder, so that I can do some touchups in the mailer
136 before sending the patch series on its way.
137 </p><p>
138 However, when running format-patch with <i>--thread</i>, it generates Message-ID
139 strings that Alpine does not like, and therefore replaces.
140 </p><p>
141 Oh, well, I'll probably just investigate how the Message-IDs are supposed to
142 look, and then use sed to rewrite the generated ones by Alpine-friendly ones
143 during the redirection to <i>postponed-msgs</i>.
144 </p><p>
145 But I alread realized that doing it that way is dramatically faster than the
146 workflow I had before.
147 </p><p>
148 And safer: no more <i>rnyn</i>.
149 </p>
150 <h6>Wednesday, 28th of January, Anno Domini MMIX, at the hour of the Buffalo</h6>
151 <a name=1233101919>
152 <h2>Progress with the interactive rebase preserving merges</h2>
153
154 <p>
155 </p><p>
156 I thought about the "dropped" commits a bit more, after all, and it is
157 probably a good thing to substitute them by their parent, as Stephen did it.
158 </p><p>
159 Imagine that you have merged a branch with two commits. One is in upstream,
160 and you want to rebase (preserving merges) onto upstream. Then you still
161 want to merge the single commit.
162 </p><p>
163 Even better, if there is no commit left, the <i>$REWRITTEN</i> mechanism will
164 substitute the commit onto which we are rebasing, so a merge will just
165 result in a fast-forward!
166 </p><p>
167 Oh, another thing: merge commits should not have a patch id, as they have
168 <u>multiple</u> patches. However, I borked the code long time ago (9c6efa36)
169 and merges get the patch-id of their diff to the first parent. Which is
170 probably wrong. So I guess I'll have to fix that with my rebase revamp.
171 </p><p>
172 So what about a root commit? If that was dropped, we will just substitute
173 it with the commit onto which we rebase (as a root commit did not really
174 have a parent, but will get the onto-commit as new parent)..
175 </p><p>
176 Now that I finally realized that t3410 is so strange because of a bug <u>I</u>
177 introduced, I can finally go about fixing it.
178 </p>
179 <h6>Wednesday, 28th of January, Anno Domini MMIX, at the hour of the Rat</h6>
180 <a name=1233099894>
181 <h2>Another midnight riddle?</h2>
182
183 <p>
184 </p><p>
185 Okay, here's another riddle: what is the next line?
186 </p><p>
187 <pre>
188 1
189 1 1
190 2 1
191 1 1 1 2
192 3 1 1 2
193 2 1 1 2 1 3
194 ...
195 </pre>
196 </p><p>
197 And when does the line get wider than 10 digits?
198 </p>
199 <h6>Tuesday, 27th of January, Anno Domini MMIX, at the hour of the Tiger</h6>
200 <a name=1233022809>
201 <h2>Fun with calculus after midnight</h2>
202
203 <p>
204 </p><p>
205 Problem: what is the shortest way of defining a variable consisting of <i>N</i>
206 spaces? I.e. for <i>N=80</i> the result will look something like
207 </p><p>
208 <table
209 border=1 bgcolor=black>
210 <tr><td bgcolor=lightblue colspan=3>
211 <pre> </pre>
212 </td></tr>
213 <tr><td>
214 <table cellspacing=5 border=0
215 style="color:white;">
216 <tr><td>
217 <pre>
218 s=' '
219 s="$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s"
220 </pre>
221 </td></tr>
222 </table>
223 </td></tr>
224 </table>
225 </p><p>
226 Let's see. Let the minimal number of characters needed be <i>A(N)</i>. For
227 simplicity, let's say that we only use one variable. Then, certainly, <i>A(N)</i>
228 cannot be larger than <i>5+N</i>, as we could define a variable using 1 character
229 for the name, 1 for the equal sign, 2 for the quotes, and one for the semicolon
230 or newline character (whichever).
231 </p><p>
232 Now, let's assume <i>N</i> is a product <i>K*L</i>. Then certainly, <i>A(N)</i> cannot
233 be larger than <i>A(K)+5+2*L</i>, as we could first define a variable that has
234 exactly <i>K</i> spaces and then use that to define the end result (in the example
235 above, <i>K=5</i> and <i>L=20</i>).
236 </p><p>
237 So, for which <i>N=K*L</i> is it better to use two definitions instead of one?
238 </p><p>
239 Simple calculus says that <i>5+K*L>5+K+5+2*L</i> must hold true, or (after some
240 scribbling): <i>L>1+7/(K-2)</i>. Which means that it makes no sense to define
241 a variable with 1 or 2 spaces first, which is kinda obvious (writing '$s'
242 alone would use two characters, so we could write the spaces right away).
243 </p><p>
244 But what for the other values? For <i>K=3</i>, <i>L</i> must be at least 9 to make
245 sense (in other words, <i>N</i> must be at least 27). For <i>K=4</i>, <i>L</i> needs
246 to be greater or equal to 5 (<i>N>=20</i>), the next pairs are <i>(5,4)</i>,
247 <i>(6,3)</i>, <i>(7,3)</i>, <i>(8,3)</i>, <i>(9,3)</i> and starting with <i>K=10</i>, any
248 <i>L>1</i> makes sense.
249 </p><p>
250 The second definition can also contain spaces at the end, however, so for any
251 <i>N=K*L+M</i>, <i>A(N)</i> cannot be larger than <i>A(K)+5+2*L+M</i>.
252 </p><p>
253 Not surprisingly, this leads to exactly the same <i>L>1+7/(K-2)</i> (as we can
254 append the <i>M</i> spaces in the last definition, no matter if we use 1 or
255 2 definitions).
256 </p><p>
257 However, that means that as soon as <i>N>=18</i>, we should use two definitions,
258 prior to that, it makes no sense.
259 </p><p>
260 So for <i>N<18</i>, <i>A(N)=5+N</i>.
261 </p><p>
262 But what <i>K</i> should one choose, i.e. how many spaces in the first definition?
263 In other words, what is <i>A(N)</i> given that we use two definitions?
264 </p><p>
265 That will have to wait for another midnight. Just a teaser: <i>A(80)=36</i>. Oh,
266 and with 80 characters, you can define a string of 9900 spaces...
267 </p>
268 <h6>Monday, 26th of January, Anno Domini MMIX, at the hour of the Dog</h6>
269 <a name=1232997290>
270 <h2>Valgrind takes a loooong time</h2>
271
272 <p>
273 </p><p>
274 Yesterday, I started a run on a fast machine, and it took roughly 5.5
275 hours by the machine's clock.
276 </p><p>
277 And of course, I redirected stdout only... *sigh*
278 </p><p>
279 Which triggered a Google search how to force redirection of all the output
280 in the test scripts to a file and the terminal at the same time.
281 </p><p>
282 It seems as if that is not easily done. I tried
283 <center><table
284 border=1 bgcolor=black>
285 <tr><td bgcolor=lightblue colspan=3>
286 <pre> </pre>
287 </td></tr>
288 <tr><td>
289 <table cellspacing=5 border=0
290 style="color:white;">
291 <tr><td>
292 <pre>
293 exec >(tee out) 2>&1
294 </pre>
295 </td></tr>
296 </table>
297 </td></tr>
298 </table></center>
299 </p><p>
300 but that did not work: it mumbled something about invalid file handles or some
301 such.
302 </p><p>
303 The only solution I found was:
304 <center><table
305 border=1 bgcolor=black>
306 <tr><td bgcolor=lightblue colspan=3>
307 <pre> </pre>
308 </td></tr>
309 <tr><td>
310 <table cellspacing=5 border=0
311 style="color:white;">
312 <tr><td>
313 <pre>
314 mkpipe pipe
315 tee out < pipe &
316 exec > pipe 2>&1
317 </pre>
318 </td></tr>
319 </table>
320 </td></tr>
321 </table></center>
322 </p><p>
323 That is a problem for parallel execution, though, so I am still looking for a
324 better way to do it.
325 </p><p>
326 Once I have the output, it is relatively easy to analyze it, as I already
327 made a script which disects the output into valgrind output and the test
328 case it came from, then groups by common valgrind output and shows the
329 result to the user.
330 </p>
331 <h6>Monday, 26th of January, Anno Domini MMIX, at the hour of the Rat</h6>
332 <a name=1232927812>
333 <h2>A day full of rebase... and a little valgrind</h2>
334
335 <p>
336 </p><p>
337 I think that I am progressing nicely with my rebase -p work, so much so
338 that I will soon be able to use it myself to work on topic branches <u>and</u>
339 rebase all the time without much hassle.
340 </p><p>
341 In other words, I would like to be able to rebase all my topic branches
342 to Junio's <i>next</i> branch whenever that has new commits. With a single
343 rebase.
344 </p><p>
345 And finally, I got the idea of the thing Stephen implemented for dropped
346 commits; however, I am quite sure I do not like it.
347 </p><p>
348 So what are "dropped" commits?
349 </p><p>
350 When you rebase, chances are that the upstream already has applied at
351 least some of your patches. So we filter those out with <i>--cherry-pick</i>.
352 Stephen calls those "dropped" commits.
353 </p><p>
354 Then he goes on to reinvent the "$REWRITTEN" system: a directory containing
355 the mappings of old commit names to new commit names. That is easily fixed.
356 </p><p>
357 But worse, he substitutes the dropped commits with their <u>parents</u>, instead
358 of substituting them with the corresponding commits in upstream.
359 </p><p>
360 I guess this will be a medium-sized fight on the mailing list, depending
361 how much energy Stephen wants to put in to defend his strategy.
362 </p><p>
363 Anyway, I finally got to a point where only three of the tests are failing,
364 t3404, t3410 and t3412. Somewhat disappointing is t3404, as its name pretends
365 not to exercize -p at all. Oh well, I guess I'll see what is broken tomorrow.
366 </p><p>
367 Another part of the day was dedicated to the Valgrind patch series, which
368 should give us yet another level of code quality.
369 </p><p>
370 After having confused myself with several diverging/obsolete branches, I did
371 indeed finally manage to send that patch series off. Woohoo.
372 </p>
373 <h6>Sunday, 25th of January, Anno Domini MMIX, at the hour of the Goat</h6>
374 <a name=1232888842>
375 <h2>Regular diff with word coloring (as opposed to word diff)</h2>
376
377 <p>
378 </p><p>
379 You know, if I were a bit faster with everything I do, I could do so much more!
380 </p><p>
381 For example, Junio's idea that you could keep showing a regular diff, only
382 coloring the words that have been removed/deleted.
383 </p><p>
384 Just imagine looking at the diff of a long line in LaTeX source code. It
385 should be much nicer to the eye to see the complete removed/added sentences
386 instead of one sentence with colored words in between, disrupting your read
387 flow.
388 </p><p>
389 Compare these two versions:
390 </p><p>
391 Regular diff with colored words:
392 <blockquote><tt>
393 -This sentence has a <font color=red>tyop</font> in it.<br>
394 +This sentence has a <font color=green>typo</font> in it.<br>
395 </tt></blockquote>
396 </p><p>
397 Word diff:
398 <blockquote><tt>
399 This sentence has a <font color=red>tyop</font><font color=green>typo</font> in it.<br>
400 </tt></blockquote>
401 </p><p>
402 And it should not be hard to do at all!
403 </p><p>
404 In <i>diff_words_show()</i>, we basically get the minus lines as
405 <i>diff_words->minus</i> and the plus lines as <i>diff_words->plus</i>. The
406 function then prepares the word lists and calls the xdiff engine to do all the
407 hard work, analyzing the result from xdiff and printing the lines in
408 <i>fn_out_diff_words_aux()</i>.
409 </p><p>
410 So all that would have to be changed would be to <u>record</u> the positions
411 of the removed/added words instead of outputting them, and at the end printing
412 the minus/plus buffers using the recorded information to color the words.
413 </p><p>
414 This would involve
415 </p><p>
416 <ul>
417 <li>adding two new members holding the offsets in the <i>diff_words</i>
418 struct,
419 <li>having a special handling for that mode in
420 <i>fn_out_diff_words_aux()</i> that appends the offsets and
421 returns,
422 <li>adding a function <i>show_lines_with_colored_words()</i> that
423 outputs a buffer with a given prefix ('-' or '+') and coloring the words at
424 given offsets with a given color,
425 <li>modify <i>diff_words_show()</i> to call that function for the "special
426 case: only removal" and at the end of the function, and
427 <li> disabling the <i>fwrite()</i> at the end of <i>diff_words_show()</i> for that
428 mode.
429 </ul>
430 </p><p>
431 Of course, the hardest part is to find a nice user interface for that. Maybe
432 <i>--colored-words</i>? &#x263a;
433 </p>
434 <h6>Saturday, 24th of January, Anno Domini MMIX, at the hour of the Pig</h6>
435 <a name=1232828715>
436 <h2>Ideas for a major revamp of the <i>--preserve-merges</i> handling in <i>git rebase</i></h2>
437
438 <p>
439 </p><p>
440 As probably everybody agrees, the code to preserve merges is a big mess
441 right now.
442 </p><p>
443 Worse, the whole concept of "pick <merge-sha1>" just does not fly well.
444 </p><p>
445 So I started a <u>major</u> cleanup, which happens to reduce the code very
446 nicely so far.
447 </p><p>
448 It will take a few days to flesh out, I guess, but these are the major
449 ideas of my work:
450 </p><p>
451 <b>pick $sha1</b><br>
452 <blockquote>will only work on non-merges in the future.</blockquote>
453 <b>merge $sha1 [$sha1...] was $sha1 Merge ...</b><br>
454 <blockquote>will merge the given list of commits into the current HEAD, for
455 the user's reference and to keep up-to-date what was rewritten,
456 the original merge is shown after the keyword "was" (which is not
457 a valid SHA-1, luckily).</blockquote>
458 <b>goto $sha1</b><br>
459 <blockquote>will reset the HEAD to the given commit.</blockquote>
460 <b>$sha1'</b><br>
461 <blockquote>for merge and goto, if a $sha1 ends in a single quote, the
462 rewritten commit is substituted (if there is one).</blockquote>
463 </p><p>
464 Example:
465 </p><p>
466 <pre>
467 A - B - - - E
468 \ /
469 C - D
470 </pre>
471 </p><p>
472 could yield this TODO script:
473 </p><p>
474 <pre>
475 pick A
476 pick C
477 pick D
478 goto A'
479 pick B
480 merge D' was E
481 </pre>
482 </p><p>
483 This should lead to a much more intuitive user experience.
484 </p><p>
485 I am very sorry if somebody actually scripted <i>rebase -i -p</i> (by setting
486 GIT_EDITOR with a script), but I am very certain that this cleanup is
487 absolutely necessary to make <i>rebase -i -p</i> useful.
488 </p>
489 <h6>Saturday, 24th of January, Anno Domini MMIX, at the hour of the Dragon</h6>
490 <a name=1232778113>
491 <h2>Thoughts about <i>interactive rebase</i></h2>
492
493 <p>
494 </p><p>
495 Somebody mentioned that my <i>my-next</i> branch is a mess, as it mixes all
496 kinds of topics.
497 </p><p>
498 That is undeniably true, however, there is a good reason that I do not
499 have a lot of topic branches: I work on more than just one computer.
500 </p><p>
501 To make sure that I do not lose a commit by mistake, I always <i>rebase -i</i>
502 the <i>my-next</i> branch of the computer I happen to work on on top of the
503 <i>my-next</i> branch I fetch from <a href=http://repo.or.cz>repo.or.cz</a>.
504 </p><p>
505 To rebase a lot of topic branches at the same time seems a bit complicated.
506 But that is actually what the <i>-p</i> option (preserve merges) is all about.
507 </p><p>
508 The only problem is that the code for <i>rebase -i -p</i> has been messed up
509 recently, quite successfully, I might add.
510 </p><p>
511 Worse, some people are pushing for a completely and total unintuitive syntax.
512 </p><p>
513 So maybe I will start to work on <i>-p</i> again, for my own use (I should learn
514 to heed the principle more: work on things I can use myself).
515 </p><p>
516 My current idea is to implement a "goto" statement that will jump to another
517 commit. To make it easily usable, I will add the semantics that "goto" will
518 always try to go to the <u>rewritten</u> version of the given commit; if the user
519 wanted to have the original commit, she has to paste the unabbreviated commit
520 name.
521 </p><p>
522 The more I think about it, the more I actually like this idea &#x263a;
523 </p><p>
524 Of course, working on this little project means that I will have to cope with
525 that ugly code again. *urgh*
526 </p>
527 </div>
528 </body>
529 </html>
Dscho's miscellaneous git branches