Update Monday, 6th of April, Anno Domini MMIX, at the hour of the Rat
[git/dscho.git] / index.html
blob9484a7c7a4de167bb93e74df403963f3c306254e
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=#1238970571>06 Apr 2009 How to recover from a hackathon</a>
16 <li><a href=#1236554268>09 Mar 2009 So, what is missing from my <i>rebase-i-p</i> branch?</a>
17 <li><a href=#1236479389>08 Mar 2009 New Git for Windows version</a>
18 <li><a href=#1235092615>20 Feb 2009 Code reviews</a>
19 <li><a href=#1234409395>12 Feb 2009 Interactive <i>rebase</i> just learnt a new command: <i>topic</i></a>
20 <li><a href=#1234320806>11 Feb 2009 Thunderbird, oh Thunderbird, you always make my small brain hurt</a>
21 <li><a href=#1234141489>09 Feb 2009 <i>format-patch --thread</i> and Alpine</a>
22 <li><a href=#1234140696>09 Feb 2009 <i>rebase</i> updates</a>
23 <li><a href=#1234040744>07 Feb 2009 The infamous <i>mark</i> command in the <i>rebase</i> command</a>
24 <li><a href=#1233707628>04 Feb 2009 New valgrind series</a>
25 </ul></p>
26 <a href=dscho.git?a=blob_plain;hb=2b3b3c28ace47f7d23df486052e6a7aa26a05e14;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://merlyn.vox.com/>Merlyn's blog</a>
65 <li> <a href=http://blogs.gnome.org/newren/>Elijah Newren</a> chose the
66 same path as Cogito, offering an alternative porcelain (an approach
67 that is doomed in my opinion)
68 <li> <a href=http://msysgit.googlecode.com/>The msysGit project</a>, a (mostly)
69 failed experiment to lure the many Windows developers out there to
70 contribute to Open Source for a change.
71 </ul>
72 </td></tr></table>
73 <br>
74 <table width=400px bgcolor=#e0e0e0 border=1>
75 <tr><th>Google Ads:</th></tr>
76 <tr><td>
77 <script type="text/javascript"><!--
78 google_ad_client = "pub-5106407705643819";
79 /* 300x250, created 1/22/09 */
80 google_ad_slot = "6468207338";
81 google_ad_width = 300;
82 google_ad_height = 250;
83 //-->
84 </script>
85 <script type="text/javascript"
86 src="http://pagead2.googlesyndication.com/pagead/show_ads.js">
87 </script>
88 </td></tr></table>
89 </div>
90 <h6>Monday, 6th of April, Anno Domini MMIX, at the hour of the Rat</h6>
91 <a name=1238970571>
92 <h2>How to recover from a hackathon</h2>
94 <p>
95 </p><p>
96 Phew, 2 crazy and fantastic weeks are behind me. But it takes its toll:
97 a weekend I was more offline than online.
98 </p><p>
99 Things that are important now: relax. sleep. take a walk. learn to sleep
100 more than 4 hours a night again. learn to watch a movie without thinking
101 about code. go for a run.
102 </p><p>
103 And after recovering, back to the rebase-i-p branch!
104 </p>
105 <h6>Monday, 9th of March, Anno Domini MMIX, at the hour of the Rat</h6>
106 <a name=1236554268>
107 <h2>So, what is missing from my <i>rebase-i-p</i> branch?</h2>
110 </p><p>
111 I regularly use <i>rebase -i -p</i> these days, to update my personal Git
112 tree (which used to be <i>my-next</i>).
113 </p><p>
114 There are a few things missing before I can start assembling a patch
115 series for submission:
116 </p><p>
117 <ul>
118 <li>I need to handle the commit parents which are outside of the rebased
119 ones properly. In other words, when a commit is picked whose parent is
120 not rebased, it needs to be rebased onto $ONTO.
121 <li>The patch which uses patch-id to generate DROPPED directly also tries to
122 consolidate the handling of DROPPED commits by putting them into REWRITTEN
123 instead of DROPPED, but that breaks the tests. So, this patch needs to be
124 split.
125 <li>I want to introduce one more command, <i>rephrase</i>, which allows you to
126 modify the commit message, and nothing more, and <i>halt</i>, which does the
127 same as <i>edit</i> without <i>pick</i>. Then there needs to be a new test script
128 for those commands, and this will be an early patch series.
129 <li>Time. I need time, desperately. If my day job was not as exciting as it
130 is, I would have more time for Git. As it is, I have to budget my time so
131 that I get anything done at all.
132 </ul>
133 </p><p>
134 These issues have been postponed due to Steffen taking a well-deserved
135 vacation, which means that I have to act as msysGit maintainer again.
136 </p><p>
137 And this coming week, I will have other things to do in all likeliness, so
138 that I expect to be able to submit a <i>rebase -i -p</i> patch series only next
139 week. If not then, due to a heavy workload, it will be postponed to early
140 April.
141 </p><p>
142 Oh well, the joys of being excited by several competing projects! &#x263a;
143 </p>
144 <h6>Sunday, 8th of March, Anno Domini MMIX, at the hour of the Tiger</h6>
145 <a name=1236479389>
146 <h2>New Git for Windows version</h2>
149 </p><p>
150 Phew. That was quite a day, almost exclusively spent on finishing that
151 installer. The worst part: updating GCC seemed not to be such a good idea
152 after all...
153 </p><p>
154 For Windows, we need to use the printf format <i>%I64u</i> (which is
155 non-standard, in the common way of Microsoft) if you want to print 64-bit
156 wide unsigned numbers. The rest of the world accepts the standard <i>%llu</i>.
157 </p><p>
158 After upgrading to the new GCC, a lot of warnings appeared, complaining
159 about <i>%I64u</i>. The warnings went away when I replaced the format with
160 <i>%llu</i>.
161 </p><p>
162 Being the naive I am, I mistook that for a sign that we could finally go
163 more standards-compliant.
164 </p><p>
165 However, it only means that we have to live with the warnings for now, as
166 the C runtime provided on Windows still strongly disagrees with standards
167 (and it has to continue to do so, lest it break existing programs).
168 </p><p>
169 Sigh.
170 </p><p>
171 At least I have the feeling that I caught the most important bugs before
172 releasing.
173 </p>
174 <h6>Friday, 20th of February, Anno Domini MMIX, at the hour of the Buffalo</h6>
175 <a name=1235092615>
176 <h2>Code reviews</h2>
179 </p><p>
180 It has been said that reviewing patches is a most thankless job. As I really
181 like the elegance of Git's source code, and care a lot about it, I did not
182 think that it was thankless, just a little bit tedious (especially when the
183 patch authors mistake criticism for personal attacks).
184 </p><p>
185 Usually, I am pretty good at ignoring insults as responses to my comments;
186 after all, I have a lot more enjoyable things to do than to spend time talking
187 to a guy who shows how wise he is when he thinks that I criticize him
188 <u>personally</u> when I just try to enhance his work, by offering a little bit of
189 my knowledge.
190 </p><p>
191 However, in the last days, three people really seemed to want to insult me,
192 to make me go away, to stop the fun I have with Git.
193 </p><p>
194 And they almost succeeded.
195 </p><p>
196 So I guess it is time to reassess my priorities, and maybe stop reviewing
197 Git patches altogether.
198 </p>
199 <h6>Thursday, 12th of February, Anno Domini MMIX, at the hour of the Tiger</h6>
200 <a name=1234409395>
201 <h2>Interactive <i>rebase</i> just learnt a new command: <i>topic</i></h2>
204 </p><p>
205 Today I am pretty pleased with myself. Two projects at my day job got a real
206 boost, and I implemented a shortcut that avoids the ugly 'bookmark' statement
207 in rebase scripts most of the time.
208 </p><p>
209 A typical rebase script, generated by <i>git rebase -i -p $COMMIT</i> will look
210 something like this:
211 </p><p>
212 <table
213 border=1 bgcolor=black>
214 <tr><td bgcolor=lightblue colspan=3>
215 <pre> </pre>
216 </td></tr>
217 <tr><td>
218 <table cellspacing=5 border=0
219 style="color:white;">
220 <tr><td>
221 <pre>
222 pick 1234567 My first commit
223 topic begin super-cool-feature
224 pick 2345678 The super cool feature
225 pick 3456789 Documentation for the super cool feature
226 topic end super-cool-feature
227 </pre>
228 </td></tr>
229 </table>
230 </td></tr>
231 </table>
232 </p><p>
233 The result will be a merge commit at the HEAD whose first parent is
234 "My first commit", whose second parent is "Documentation for the super
235 cool feature" and whose commit message is "Merge branch 'super-cool-feature'".
236 </p><p>
237 Side note: internally, <i>topic begin $NAME [at $COMMIT]</i> will be handled as if
238 you wrote <i>bookmark merge-parent-of-$NAME; goto $COMMIT</i>, and
239 <i>topic end $NAME [$MESSAGE]</i> will be handled as if you wrote
240 <i>bookmark $NAME; goto merge-parent-of-$NAME; merge parents $NAME [original $MARK Merge branch '$NAME']</i>.
241 </p><p>
242 Of course, being more concise, the 'topic' statement is not only nicer to the
243 eye, but also less error-prone.
244 </p><p>
245 And hopefully many people will agree with me that this rebase script is pretty
246 intuitive.
247 </p>
248 <h6>Wednesday, 11th of February, Anno Domini MMIX, at the hour of the Tiger</h6>
249 <a name=1234320806>
250 <h2>Thunderbird, oh Thunderbird, you always make my small brain hurt</h2>
253 </p><p>
254 There was a lengthy discussion on the Git mailing list about using Thunderbird,
255 a not quite unpopular mailing program, to send inline patches.
256 </p><p>
257 It is really kind of sad that the Thunderbird developers do not see how
258 stubbornly they offend quite a number of people and scare them away from their
259 program. After all, you should try to be liberal in what you accept and strict
260 in what you emit. No, that does not mean that you should force others to
261 switch their mailers because you strictly adher to your philosophy in what you
262 emit, ignoring the rest of the world.
263 </p><p>
264 In any case, I am not affected (as long as I do not get mails from a poor soul
265 stuck with Thunderbird).
266 </p><p>
267 But I was a bit mean to that Thunderbird guy I dragged into the discussion, and
268 he seems really offended.
269 </p><p>
270 So I thought I'd give him a real reason to feel offended: I'll just do his work:
271 </p><p>
272 http://<a href=http://repo.or.cz>repo.or.cz</a>/w/UnFlowedThunderbird.git
273 </p><p>
274 It took my free time of two days, being not a Thunderbird developer myself.
275 Hopefully it works, and hopefully some people will feel really ashamed now.
276 </p>
277 <h6>Monday, 9th of February, Anno Domini MMIX, at the hour of the Buffalo</h6>
278 <a name=1234141489>
279 <h2><i>format-patch --thread</i> and Alpine</h2>
282 </p><p>
283 I started recently to pipe the output of
284 <i>git format-patch --cover-letter --stdout ...</i> directly into the
285 <i>postponed-msgs</i> folder Alpine uses, instead of pasting files into the
286 mailer.
287 </p><p>
288 The idea is to pretend that I continue a postponed mail, but in reality I
289 never wrote it, <i>format-patch</i> did.
290 </p><p>
291 However, I had problems with the <i>--thread</i> option that is implied by
292 <i>--cover-letter</i>. Alpine always generated new message IDs without adjusting
293 the <i>In-reply-to:</i> and <i>References:</i> headers of the other mails.
294 </p><p>
295 Now I found out that the reason is that the <i>Fcc:</i> headers were missing in
296 the mails, and Alpine generated them, making up new message IDs in the process.
297 </p><p>
298 Therefore I have an alias now which sets not only the <i>Fcc:</i> header, but also
299 the <i>To:</i> headers by rewriting the stream using <i>sed</i>. This is slightly
300 ugly, but so is the handling of headers in <i>format-patch</i>: if you thought
301 you could specify arbitrary headers using the command line, you are mistaken:
302 you can do that only by editing the config.
303 </p><p>
304 While at it, I also noticed a bug whereby <i>--thread --in-reply-to=...</i> simply
305 forgets the <i>--thread</i>. Maybe this week I will find time to address this bug.
306 </p>
307 <h6>Monday, 9th of February, Anno Domini MMIX, at the hour of the Buffalo</h6>
308 <a name=1234140696>
309 <h2><i>rebase</i> updates</h2>
312 </p><p>
313 Phew. The last few days, I was mainly chasing bugs I introduced due to being
314 too tired to work on the merge-preserving, interactive <i>rebase</i>.
315 </p><p>
316 But finally I have something I can start working with. After my failed
317 experiment to use git-blame to split topic branches, I will sort the commits
318 in my <i>my-next</i> branch into topic branches manually.
319 </p><p>
320 Then I will add an option to <i>rebase -i -p</i> to rewrite refs which point to
321 rewritten commits, so that I can have branches <i>rebase-i-p</i>, <i>add-e</i>, etc
322 and all of them are automatically updated when I <i>rebase -i -p</i> the <i>my-next</i>
323 branch.
324 </p><p>
325 In the process, not only have I learnt the value of the <i>bookmark</i> command,
326 but made quite a few-much needed cleanups (which make
327 <i>git-rebase--interactive.sh</i> longer, but much more understandable).
328 </p><p>
329 Hopefully Stephan will pick the changes in the "rebase protocol" up, and then
330 we can have a sequencer with which I can start to make a graphical interactive
331 rebase using git-gui. Or gitk.
332 </p><p>
333 Maybe.
334 </p>
335 <h6>Saturday, 7th of February, Anno Domini MMIX, at the hour of the Pig</h6>
336 <a name=1234040744>
337 <h2>The infamous <i>mark</i> command in the <i>rebase</i> command</h2>
340 </p><p>
341 I realized today how easy it is to lose commits with the "merge preserving"
342 mode of the interactive rebase. In my case, it was when I tried to move a
343 bunch of commits from the tip of my branch into a topic branch.
344 </p><p>
345 But after moving the commits, I forgot to update the parent of the merge
346 commit. Possibly a mark command could have helped. The very same command
347 I called a nightmare for usability.
348 </p><p>
349 So I was wrong. Big news. &#x263a;
350 </p><p>
351 However, I think that the syntax "mark :1" is something best left for
352 machine consumption, not for human beings.
353 </p><p>
354 But I have an idea: we could use some garbled commit subject, or in case of
355 merge parents, the merge subject as some human readable title of the mark.
356 </p><p>
357 The rebase script would then look something like this:
358 </p><p>
359 <table
360 border=1 bgcolor=black>
361 <tr><td bgcolor=lightblue colspan=3>
362 <pre> </pre>
363 </td></tr>
364 <tr><td>
365 <table cellspacing=5 border=0
366 style="color:white;">
367 <tr><td>
368 <pre>
369 pick abcdefg Some ultra cool commit
370 bookmark ultra-cool
371 goto upstream
372 pick hijklmn Some other cool commit
373 merge parent ultra-cool Merge 'ultra-cool' into master
374 </pre>
375 </td></tr>
376 </table>
377 </td></tr>
378 </table>
379 </p><p>
380 The good news is: I added code that refuses to finish a rebase when there
381 are commits that were rewritten, but not part of the new HEAD's ancestry.
382 </p>
383 <h6>Wednesday, 4th of February, Anno Domini MMIX, at the hour of the Buffalo</h6>
384 <a name=1233707628>
385 <h2>New valgrind series</h2>
388 </p><p>
389 I spent quite some time cleaning up that patch series, and feel pretty
390 exhausted.
391 </p><p>
392 Granted, the new <i>git rebase -i -p</i> does its job without complaint so far
393 (so much so that I think I'll release a version of my <i>rebase</i> series
394 soonish), but it <u>is</u> a hassle when you have patches that you have a hard
395 time to decide upon the order/commit boundaries.
396 </p><p>
397 For example, I could imagine that the patch making the location of the
398 templates independent of the location of the Git binaries should come
399 <u>before</u> my patch series, and the valgrind specific part should then
400 be squashed into the first valgrind commit.
401 </p><p>
402 Also, it uses two features of valgrind 3.4.0:
403 </p><p>
404 <ul>
405 <li><i>...</i> in the suppression file, and
406 <li><i>--track-origins=yes</i>
407 </ul>
408 </p><p>
409 The latter is actually the reason I am pretty willing to keep the
410 requirement of that valgrind version, as it is really, really useful.
411 </p><p>
412 I guess we will see what happens to it.
413 </p>
414 </div>
415 </body>
416 </html>