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