| blob | 63f608db655fb2a0e88bfa4d159d3df1b0c3d5cd |
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 dilemma of being correct
16 </p><p>
17 So I am opinionated. No news there. The problem of being opinionated, though,
18 is that people do not take you seriously even if you are correct.
19 </p><p>
20 For example, I vividly remember having had concerns about the Git wrapper
22 that our maintainer did not have such concerns and took Daniel's patch. I could
23 not find proof of my public comment quickly enough to add a link here, though.
24 </p><p>
25 Alas, there are serious problems with being correct:
26 </p><p>
27 <ol>
28 <li>If you're correct, you waste a lot of time trying to convince people (but
29 they ignore you nevertheless),
30 <li>Other people are regularly p*ssed off, especially when they find out
31 (or even worse, when it is pointed out to them) that they were wrong, and
33 </ol>
34 </p><p>
35 It is a lose-lose situation.
36 </p><p>
37 In the current context, I am pretty certain that the rev cache and the pack
38 index are so similar in nature that we'll find quite a few issues that we had
39 with one repeated with the other.
40 </p><p>
42 invariably means that they refuse to be convinced of anything disagreeing with
43 their opinion ☺ -- I will just shut up, and probably have one or two odd
44 feelings when it turns out I was right.]]></description>
45 </item>
46 <item>
51 <description><![CDATA[The GraphGUI project
52 </p><p>
53 After a few unfortunate delays (and some fortunate ones, just not for us), the
54 GraphGUI project finally takes off. A quick first glance:
55 </p><p>
56 <center><img src=dscho.git?a=blob_plain;hb=c33212b23b2b3e45c14403efe82cabb1cd53f6e3;f=basic-gui.jpg basic-gui.jpg></center>
57 </p><p>
58 The delays were a bit unnerving, but the student is really bright and still
59 has the chance to pull the project off.
60 </p><p>
61 Next plans are to show text, too, to invent a rudimentary layout engine that
63 </p><p>
64 After that, integration into JGit (this probably triggered the eGit/JGit
65 split).
66 </p><p>
67 And then we'll go wild!]]></description>
68 </item>
69 <item>
74 <description><![CDATA[Wasting way too much time on msysGit
75 </p><p>
76 I recently got into the bad habit of spending a large amount of my waking
77 hours working on msysGit, more than is really healthy for me.
78 </p><p>
79 For example, I spent the whole morning -- when I should have worked on a
80 very important day-job project -- on trying to fix issue 258, where
82 with cmd.exe.
83 </p><p>
84 This is reducing my Git time budget to negative numbers, so much so that I
88 </p><p>
89 Now, some people who tried to teach me some time management strongly
90 criticized me for ignoring their lessons, and unfortunately, I have to agree.
91 </p><p>
93 was after I stopped working on it last year. I started it, and I would like
94 it to grow, but too few people took care of the issue tracker, too few tried
95 to debug their problems themselves, too few submitted fixes.
96 </p><p>
97 I note, though, that there is a positive trend. But being the impatient person
98 I am ("2 seconds is my attention span") I tend to want the trend to be more
99 impressive.
100 </p><p>
101 Anyway, no work on msysGit for at least 4 days, that's what the doctor (me)
102 said...]]></description>
103 </item>
104 <item>
109 <description><![CDATA[Working on jgit diff
110 </p><p>
111 Shawn did so many useful things that I use on a daily basis that I felt really
113 implementation I wrote for JGit.
114 </p><p>
115 Alas, it appears that the thing turned out to be almost a complete rewrite, as
116 the original implementation walked the edit graph in a rather inefficient way.
117 </p><p>
118 A little background: Myers' algorithm to generate "an edit script" works on
121 the upper left corner to the lower right corner, containing only horizontal,
122 vertical or diagonal elements, where diagonal elements are only allowed when
123 the lines of both files agree at that point:
124 </p><p>
125 <pre>
126 H E L L O , W O R L D
127 ----
128 L \
129 ---
130 O \
131 ---
132 W \
133 --------
134 </pre>
135 </p><p>
137 </p><p>
138 Myers' idea is to develop forward and backward paths at the same time
139 (increasing the number of non-diagonal elements uniformly), storing
140 only the latest end points. Once the paths meet, divide and conquer.
141 </p><p>
143 reconstruct the shortest paths, alas, this takes way too much memory.
144 </p><p>
145 My first implementation did not remember start or end of the non-diagonal
146 parts, and had to recurse way more often than really necessary (in the end,
147 we will order the non-diagonal parts into horizontal and vertical parts
148 anyway, so start and end are sufficient).
149 </p><p>
152 </item>
153 <item>
158 <description><![CDATA[No time for Git
159 </p><p>
160 It is a shame, but most of my Git time budget is taken by msysGit these
161 days.
162 </p><p>
163 But at least msysGit is moving again; I'll probably write a Herald about
164 it.]]></description>
165 </item>
166 <item>
171 <description><![CDATA[How to recover from a hackathon
172 </p><p>
173 Phew, 2 crazy and fantastic weeks are behind me. But it takes its toll:
174 a weekend I was more offline than online.
175 </p><p>
176 Things that are important now: relax. sleep. take a walk. learn to sleep
177 more than 4 hours a night again. learn to watch a movie without thinking
178 about code. go for a run.
179 </p><p>
180 And after recovering, back to the rebase-i-p branch!]]></description>
181 </item>
182 <item>
188 </p><p>
191 </p><p>
192 There are a few things missing before I can start assembling a patch
193 series for submission:
194 </p><p>
195 <ul>
196 <li>I need to handle the commit parents which are outside of the rebased
197 ones properly. In other words, when a commit is picked whose parent is
198 not rebased, it needs to be rebased onto $ONTO.
199 <li>The patch which uses patch-id to generate DROPPED directly also tries to
200 consolidate the handling of DROPPED commits by putting them into REWRITTEN
201 instead of DROPPED, but that breaks the tests. So, this patch needs to be
202 split.
206 for those commands, and this will be an early patch series.
207 <li>Time. I need time, desperately. If my day job was not as exciting as it
208 is, I would have more time for Git. As it is, I have to budget my time so
209 that I get anything done at all.
210 </ul>
211 </p><p>
212 These issues have been postponed due to Steffen taking a well-deserved
213 vacation, which means that I have to act as msysGit maintainer again.
214 </p><p>
215 And this coming week, I will have other things to do in all likeliness, so
217 week. If not then, due to a heavy workload, it will be postponed to early
218 April.
219 </p><p>
221 </item>
222 <item>
227 <description><![CDATA[New Git for Windows version
228 </p><p>
229 Phew. That was quite a day, almost exclusively spent on finishing that
230 installer. The worst part: updating GCC seemed not to be such a good idea
231 after all...
232 </p><p>
234 non-standard, in the common way of Microsoft) if you want to print 64-bit
236 </p><p>
237 After upgrading to the new GCC, a lot of warnings appeared, complaining
240 </p><p>
241 Being the naive I am, I mistook that for a sign that we could finally go
242 more standards-compliant.
243 </p><p>
244 However, it only means that we have to live with the warnings for now, as
245 the C runtime provided on Windows still strongly disagrees with standards
246 (and it has to continue to do so, lest it break existing programs).
247 </p><p>
248 Sigh.
249 </p><p>
250 At least I have the feeling that I caught the most important bugs before
251 releasing.]]></description>
252 </item>
253 <item>
258 <description><![CDATA[Code reviews
259 </p><p>
260 It has been said that reviewing patches is a most thankless job. As I really
261 like the elegance of Git's source code, and care a lot about it, I did not
262 think that it was thankless, just a little bit tedious (especially when the
263 patch authors mistake criticism for personal attacks).
264 </p><p>
265 Usually, I am pretty good at ignoring insults as responses to my comments;
266 after all, I have a lot more enjoyable things to do than to spend time talking
267 to a guy who shows how wise he is when he thinks that I criticize him
269 my knowledge.
270 </p><p>
271 However, in the last days, three people really seemed to want to insult me,
272 to make me go away, to stop the fun I have with Git.
273 </p><p>
274 And they almost succeeded.
275 </p><p>
276 So I guess it is time to reassess my priorities, and maybe stop reviewing
277 Git patches altogether.]]></description>
278 </item>
279 <item>
285 </p><p>
286 Today I am pretty pleased with myself. Two projects at my day job got a real
287 boost, and I implemented a shortcut that avoids the ugly 'bookmark' statement
288 in rebase scripts most of the time.
289 </p><p>
291 something like this:
292 </p><p>
293 <table
296 <pre> </pre>
297 </td></tr>
298 <tr><td>
301 <tr><td>
302 <pre>
303 pick 1234567 My first commit
304 topic begin super-cool-feature
305 pick 2345678 The super cool feature
306 pick 3456789 Documentation for the super cool feature
307 topic end super-cool-feature
308 </pre>
309 </td></tr>
310 </table>
311 </td></tr>
312 </table>
313 </p><p>
314 The result will be a merge commit at the HEAD whose first parent is
317 </p><p>
321 <i>bookmark $NAME; goto merge-parent-of-$NAME; merge parents $NAME [original $MARK Merge branch '$NAME']</i>.
322 </p><p>
323 Of course, being more concise, the 'topic' statement is not only nicer to the
324 eye, but also less error-prone.
325 </p><p>
326 And hopefully many people will agree with me that this rebase script is pretty
327 intuitive.]]></description>
328 </item>
329 </channel>
330 </rss>