| blob | 791b830862f4a02515f0137ff7acf850e958b9a4 |
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[The GraphGUI project
16 </p><p>
17 After a few unfortunate delays (and some fortunate ones, just not for us), the
18 GraphGUI project finally takes off. A quick first glance:
19 </p><p>
21 </p><p>
22 The delays were a bit unnerving, but the student is really bright and still
23 has the chance to pull the project off.
24 </p><p>
25 Next plans are to show text, too, to invent a rudimentary layout engine that
27 </p><p>
28 After that, integration into JGit (this probably triggered the eGit/JGit
29 split).
30 </p><p>
31 And then we'll go wild!]]></description>
32 </item>
33 <item>
38 <description><![CDATA[Wasting way too much time on msysGit
39 </p><p>
40 I recently got into the bad habit of spending a large amount of my waking
41 hours working on msysGit, more than is really healthy for me.
42 </p><p>
43 For example, I spent the whole morning -- when I should have worked on a
44 very important day-job project -- on trying to fix issue 258, where
46 with cmd.exe.
47 </p><p>
48 This is reducing my Git time budget to negative numbers, so much so that I
52 </p><p>
53 Now, some people who tried to teach me some time management strongly
54 criticized me for ignoring their lessons, and unfortunately, I have to agree.
55 </p><p>
57 was after I stopped working on it last year. I started it, and I would like
58 it to grow, but too few people took care of the issue tracker, too few tried
59 to debug their problems themselves, too few submitted fixes.
60 </p><p>
61 I note, though, that there is a positive trend. But being the impatient person
62 I am ("2 seconds is my attention span") I tend to want the trend to be more
63 impressive.
64 </p><p>
65 Anyway, no work on msysGit for at least 4 days, that's what the doctor (me)
66 said...]]></description>
67 </item>
68 <item>
73 <description><![CDATA[Working on jgit diff
74 </p><p>
75 Shawn did so many useful things that I use on a daily basis that I felt really
77 implementation I wrote for JGit.
78 </p><p>
79 Alas, it appears that the thing turned out to be almost a complete rewrite, as
80 the original implementation walked the edit graph in a rather inefficient way.
81 </p><p>
82 A little background: Myers' algorithm to generate "an edit script" works on
85 the upper left corner to the lower right corner, containing only horizontal,
86 vertical or diagonal elements, where diagonal elements are only allowed when
87 the lines of both files agree at that point:
88 </p><p>
89 <pre>
90 H E L L O , W O R L D
91 ----
92 L \
93 ---
94 O \
95 ---
96 W \
97 --------
98 </pre>
99 </p><p>
101 </p><p>
102 Myers' idea is to develop forward and backward paths at the same time
103 (increasing the number of non-diagonal elements uniformly), storing
104 only the latest end points. Once the paths meet, divide and conquer.
105 </p><p>
107 reconstruct the shortest paths, alas, this takes way too much memory.
108 </p><p>
109 My first implementation did not remember start or end of the non-diagonal
110 parts, and had to recurse way more often than really necessary (in the end,
111 we will order the non-diagonal parts into horizontal and vertical parts
112 anyway, so start and end are sufficient).
113 </p><p>
116 </item>
117 <item>
122 <description><![CDATA[No time for Git
123 </p><p>
124 It is a shame, but most of my Git time budget is taken by msysGit these
125 days.
126 </p><p>
127 But at least msysGit is moving again; I'll probably write a Herald about
128 it.]]></description>
129 </item>
130 <item>
135 <description><![CDATA[How to recover from a hackathon
136 </p><p>
137 Phew, 2 crazy and fantastic weeks are behind me. But it takes its toll:
138 a weekend I was more offline than online.
139 </p><p>
140 Things that are important now: relax. sleep. take a walk. learn to sleep
141 more than 4 hours a night again. learn to watch a movie without thinking
142 about code. go for a run.
143 </p><p>
144 And after recovering, back to the rebase-i-p branch!]]></description>
145 </item>
146 <item>
152 </p><p>
155 </p><p>
156 There are a few things missing before I can start assembling a patch
157 series for submission:
158 </p><p>
159 <ul>
160 <li>I need to handle the commit parents which are outside of the rebased
161 ones properly. In other words, when a commit is picked whose parent is
162 not rebased, it needs to be rebased onto $ONTO.
163 <li>The patch which uses patch-id to generate DROPPED directly also tries to
164 consolidate the handling of DROPPED commits by putting them into REWRITTEN
165 instead of DROPPED, but that breaks the tests. So, this patch needs to be
166 split.
170 for those commands, and this will be an early patch series.
171 <li>Time. I need time, desperately. If my day job was not as exciting as it
172 is, I would have more time for Git. As it is, I have to budget my time so
173 that I get anything done at all.
174 </ul>
175 </p><p>
176 These issues have been postponed due to Steffen taking a well-deserved
177 vacation, which means that I have to act as msysGit maintainer again.
178 </p><p>
179 And this coming week, I will have other things to do in all likeliness, so
181 week. If not then, due to a heavy workload, it will be postponed to early
182 April.
183 </p><p>
185 </item>
186 <item>
191 <description><![CDATA[New Git for Windows version
192 </p><p>
193 Phew. That was quite a day, almost exclusively spent on finishing that
194 installer. The worst part: updating GCC seemed not to be such a good idea
195 after all...
196 </p><p>
198 non-standard, in the common way of Microsoft) if you want to print 64-bit
200 </p><p>
201 After upgrading to the new GCC, a lot of warnings appeared, complaining
204 </p><p>
205 Being the naive I am, I mistook that for a sign that we could finally go
206 more standards-compliant.
207 </p><p>
208 However, it only means that we have to live with the warnings for now, as
209 the C runtime provided on Windows still strongly disagrees with standards
210 (and it has to continue to do so, lest it break existing programs).
211 </p><p>
212 Sigh.
213 </p><p>
214 At least I have the feeling that I caught the most important bugs before
215 releasing.]]></description>
216 </item>
217 <item>
222 <description><![CDATA[Code reviews
223 </p><p>
224 It has been said that reviewing patches is a most thankless job. As I really
225 like the elegance of Git's source code, and care a lot about it, I did not
226 think that it was thankless, just a little bit tedious (especially when the
227 patch authors mistake criticism for personal attacks).
228 </p><p>
229 Usually, I am pretty good at ignoring insults as responses to my comments;
230 after all, I have a lot more enjoyable things to do than to spend time talking
231 to a guy who shows how wise he is when he thinks that I criticize him
233 my knowledge.
234 </p><p>
235 However, in the last days, three people really seemed to want to insult me,
236 to make me go away, to stop the fun I have with Git.
237 </p><p>
238 And they almost succeeded.
239 </p><p>
240 So I guess it is time to reassess my priorities, and maybe stop reviewing
241 Git patches altogether.]]></description>
242 </item>
243 <item>
249 </p><p>
250 Today I am pretty pleased with myself. Two projects at my day job got a real
251 boost, and I implemented a shortcut that avoids the ugly 'bookmark' statement
252 in rebase scripts most of the time.
253 </p><p>
255 something like this:
256 </p><p>
257 <table
260 <pre> </pre>
261 </td></tr>
262 <tr><td>
265 <tr><td>
266 <pre>
267 pick 1234567 My first commit
268 topic begin super-cool-feature
269 pick 2345678 The super cool feature
270 pick 3456789 Documentation for the super cool feature
271 topic end super-cool-feature
272 </pre>
273 </td></tr>
274 </table>
275 </td></tr>
276 </table>
277 </p><p>
278 The result will be a merge commit at the HEAD whose first parent is
281 </p><p>
285 <i>bookmark $NAME; goto merge-parent-of-$NAME; merge parents $NAME [original $MARK Merge branch '$NAME']</i>.
286 </p><p>
287 Of course, being more concise, the 'topic' statement is not only nicer to the
288 eye, but also less error-prone.
289 </p><p>
290 And hopefully many people will agree with me that this rebase script is pretty
291 intuitive.]]></description>
292 </item>
293 <item>
298 <description><![CDATA[Thunderbird, oh Thunderbird, you always make my small brain hurt
299 </p><p>
300 There was a lengthy discussion on the Git mailing list about using Thunderbird,
301 a not quite unpopular mailing program, to send inline patches.
302 </p><p>
303 It is really kind of sad that the Thunderbird developers do not see how
304 stubbornly they offend quite a number of people and scare them away from their
305 program. After all, you should try to be liberal in what you accept and strict
306 in what you emit. No, that does not mean that you should force others to
307 switch their mailers because you strictly adher to your philosophy in what you
308 emit, ignoring the rest of the world.
309 </p><p>
310 In any case, I am not affected (as long as I do not get mails from a poor soul
311 stuck with Thunderbird).
312 </p><p>
313 But I was a bit mean to that Thunderbird guy I dragged into the discussion, and
314 he seems really offended.
315 </p><p>
316 So I thought I'd give him a real reason to feel offended: I'll just do his work:
317 </p><p>
318 http://repo.or.cz/w/UnFlowedThunderbird.git
319 </p><p>
320 It took my free time of two days, being not a Thunderbird developer myself.
321 Hopefully it works, and hopefully some people will feel really ashamed now.]]></description>
322 </item>
323 </channel>
324 </rss>