| blob | ae8b5a3a300a81424748779ff565b01c14b02939 |
3 <channel>
6 <atom:link href="http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=blog.rss" rel="self" type="application/rss+xml"/>
10 <item>
15 <description><![CDATA[How to recover from a hackathon
16 </p><p>
17 Phew, 2 crazy and fantastic weeks are behind me. But it takes its toll:
18 a weekend I was more offline than online.
19 </p><p>
20 Things that are important now: relax. sleep. take a walk. learn to sleep
21 more than 4 hours a night again. learn to watch a movie without thinking
22 about code. go for a run.
23 </p><p>
24 And after recovering, back to the rebase-i-p branch!]]></description>
25 </item>
26 <item>
32 </p><p>
35 </p><p>
36 There are a few things missing before I can start assembling a patch
37 series for submission:
38 </p><p>
39 <ul>
40 <li>I need to handle the commit parents which are outside of the rebased
41 ones properly. In other words, when a commit is picked whose parent is
42 not rebased, it needs to be rebased onto $ONTO.
43 <li>The patch which uses patch-id to generate DROPPED directly also tries to
44 consolidate the handling of DROPPED commits by putting them into REWRITTEN
45 instead of DROPPED, but that breaks the tests. So, this patch needs to be
46 split.
50 for those commands, and this will be an early patch series.
51 <li>Time. I need time, desperately. If my day job was not as exciting as it
52 is, I would have more time for Git. As it is, I have to budget my time so
53 that I get anything done at all.
54 </ul>
55 </p><p>
56 These issues have been postponed due to Steffen taking a well-deserved
57 vacation, which means that I have to act as msysGit maintainer again.
58 </p><p>
59 And this coming week, I will have other things to do in all likeliness, so
61 week. If not then, due to a heavy workload, it will be postponed to early
62 April.
63 </p><p>
65 </item>
66 <item>
71 <description><![CDATA[New Git for Windows version
72 </p><p>
73 Phew. That was quite a day, almost exclusively spent on finishing that
74 installer. The worst part: updating GCC seemed not to be such a good idea
75 after all...
76 </p><p>
78 non-standard, in the common way of Microsoft) if you want to print 64-bit
80 </p><p>
81 After upgrading to the new GCC, a lot of warnings appeared, complaining
84 </p><p>
85 Being the naive I am, I mistook that for a sign that we could finally go
86 more standards-compliant.
87 </p><p>
88 However, it only means that we have to live with the warnings for now, as
89 the C runtime provided on Windows still strongly disagrees with standards
90 (and it has to continue to do so, lest it break existing programs).
91 </p><p>
92 Sigh.
93 </p><p>
94 At least I have the feeling that I caught the most important bugs before
95 releasing.]]></description>
96 </item>
97 <item>
102 <description><![CDATA[Code reviews
103 </p><p>
104 It has been said that reviewing patches is a most thankless job. As I really
105 like the elegance of Git's source code, and care a lot about it, I did not
106 think that it was thankless, just a little bit tedious (especially when the
107 patch authors mistake criticism for personal attacks).
108 </p><p>
109 Usually, I am pretty good at ignoring insults as responses to my comments;
110 after all, I have a lot more enjoyable things to do than to spend time talking
111 to a guy who shows how wise he is when he thinks that I criticize him
113 my knowledge.
114 </p><p>
115 However, in the last days, three people really seemed to want to insult me,
116 to make me go away, to stop the fun I have with Git.
117 </p><p>
118 And they almost succeeded.
119 </p><p>
120 So I guess it is time to reassess my priorities, and maybe stop reviewing
121 Git patches altogether.]]></description>
122 </item>
123 <item>
129 </p><p>
130 Today I am pretty pleased with myself. Two projects at my day job got a real
131 boost, and I implemented a shortcut that avoids the ugly 'bookmark' statement
132 in rebase scripts most of the time.
133 </p><p>
135 something like this:
136 </p><p>
137 <table
140 <pre> </pre>
141 </td></tr>
142 <tr><td>
145 <tr><td>
146 <pre>
147 pick 1234567 My first commit
148 topic begin super-cool-feature
149 pick 2345678 The super cool feature
150 pick 3456789 Documentation for the super cool feature
151 topic end super-cool-feature
152 </pre>
153 </td></tr>
154 </table>
155 </td></tr>
156 </table>
157 </p><p>
158 The result will be a merge commit at the HEAD whose first parent is
161 </p><p>
165 <i>bookmark $NAME; goto merge-parent-of-$NAME; merge parents $NAME [original $MARK Merge branch '$NAME']</i>.
166 </p><p>
167 Of course, being more concise, the 'topic' statement is not only nicer to the
168 eye, but also less error-prone.
169 </p><p>
170 And hopefully many people will agree with me that this rebase script is pretty
171 intuitive.]]></description>
172 </item>
173 <item>
178 <description><![CDATA[Thunderbird, oh Thunderbird, you always make my small brain hurt
179 </p><p>
180 There was a lengthy discussion on the Git mailing list about using Thunderbird,
181 a not quite unpopular mailing program, to send inline patches.
182 </p><p>
183 It is really kind of sad that the Thunderbird developers do not see how
184 stubbornly they offend quite a number of people and scare them away from their
185 program. After all, you should try to be liberal in what you accept and strict
186 in what you emit. No, that does not mean that you should force others to
187 switch their mailers because you strictly adher to your philosophy in what you
188 emit, ignoring the rest of the world.
189 </p><p>
190 In any case, I am not affected (as long as I do not get mails from a poor soul
191 stuck with Thunderbird).
192 </p><p>
193 But I was a bit mean to that Thunderbird guy I dragged into the discussion, and
194 he seems really offended.
195 </p><p>
196 So I thought I'd give him a real reason to feel offended: I'll just do his work:
197 </p><p>
199 </p><p>
200 It took my free time of two days, being not a Thunderbird developer myself.
201 Hopefully it works, and hopefully some people will feel really ashamed now.]]></description>
202 </item>
203 <item>
209 </p><p>
210 I started recently to pipe the output of
213 mailer.
214 </p><p>
215 The idea is to pretend that I continue a postponed mail, but in reality I
217 </p><p>
221 </p><p>
223 the mails, and Alpine generated them, making up new message IDs in the process.
224 </p><p>
228 you could specify arbitrary headers using the command line, you are mistaken:
229 you can do that only by editing the config.
230 </p><p>
232 forgets the <i>--thread</i>. Maybe this week I will find time to address this bug.]]></description>
233 </item>
234 <item>
240 </p><p>
241 Phew. The last few days, I was mainly chasing bugs I introduced due to being
243 </p><p>
244 But finally I have something I can start working with. After my failed
245 experiment to use git-blame to split topic branches, I will sort the commits
247 </p><p>
251 branch.
252 </p><p>
254 but made quite a few-much needed cleanups (which make
256 </p><p>
257 Hopefully Stephan will pick the changes in the "rebase protocol" up, and then
258 we can have a sequencer with which I can start to make a graphical interactive
259 rebase using git-gui. Or gitk.
260 </p><p>
261 Maybe.]]></description>
262 </item>
263 <item>
269 </p><p>
270 I realized today how easy it is to lose commits with the "merge preserving"
271 mode of the interactive rebase. In my case, it was when I tried to move a
272 bunch of commits from the tip of my branch into a topic branch.
273 </p><p>
274 But after moving the commits, I forgot to update the parent of the merge
275 commit. Possibly a mark command could have helped. The very same command
276 I called a nightmare for usability.
277 </p><p>
278 So I was wrong. Big news. ☺
279 </p><p>
280 However, I think that the syntax "mark :1" is something best left for
281 machine consumption, not for human beings.
282 </p><p>
283 But I have an idea: we could use some garbled commit subject, or in case of
284 merge parents, the merge subject as some human readable title of the mark.
285 </p><p>
286 The rebase script would then look something like this:
287 </p><p>
288 <table
291 <pre> </pre>
292 </td></tr>
293 <tr><td>
296 <tr><td>
297 <pre>
298 pick abcdefg Some ultra cool commit
299 bookmark ultra-cool
300 goto upstream
301 pick hijklmn Some other cool commit
302 merge parent ultra-cool Merge 'ultra-cool' into master
303 </pre>
304 </td></tr>
305 </table>
306 </td></tr>
307 </table>
308 </p><p>
309 The good news is: I added code that refuses to finish a rebase when there
310 are commits that were rewritten, but not part of the new HEAD's ancestry.]]></description>
311 </item>
312 <item>
317 <description><![CDATA[New valgrind series
318 </p><p>
319 I spent quite some time cleaning up that patch series, and feel pretty
320 exhausted.
321 </p><p>
325 time to decide upon the order/commit boundaries.
326 </p><p>
327 For example, I could imagine that the patch making the location of the
328 templates independent of the location of the Git binaries should come
330 be squashed into the first valgrind commit.
331 </p><p>
332 Also, it uses two features of valgrind 3.4.0:
333 </p><p>
334 <ul>
337 </ul>
338 </p><p>
339 The latter is actually the reason I am pretty willing to keep the
340 requirement of that valgrind version, as it is really, really useful.
341 </p><p>
342 I guess we will see what happens to it.]]></description>
343 </item>
344 </channel>
345 </rss>