| blob | 2a343ff5e11cbfee35f3d91269c8127a747bc1aa |
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[GitTogether in Berlin
16 </p><p>
18 wurde Git"). It was great fun, we never had even a single boring minute,
19 and our special guest -- Gitzilla -- turned out to be quite some entertainer,
20 especially when he starting reciting a few of my most outrageous emails ☺
21 </p><p>
22 There were a lot of good discussions, among other things about submodules (our
23 neglected child), Git Cheetah, and foreign VCS helpers (in particular Sverre's
24 plan to provide some Mercurial backend).
25 </p><p>
26 One of the most important outcomes for me was, though, to realize just how
27 detached we in the Git project are from our user base. A few years back, we
28 could get away with saying "we have only developers as users, so they should
29 just sit down and scratch their own itch".
30 </p><p>
31 But today, we have a lot of users who never learnt to code (or who code in
32 some other language than C, or whose code we would not even want to review ☺),
33 and we lose quite a few brownie points by keeping things complicated.
34 </p><p>
35 Now, in a lot of cases it cannot be helped. For example, we have confusing
37 branches), and we have some odd design decisions (like calling some program
38 almost nobody uses "git cherry", which makes tab-completion of the rather
39 often-used "git cherry-pick" pretty awkward). The latter example also
40 illustrates that we have names for porcelains that are rather long, when
41 they should be rather short.
42 </p><p>
43 So, yes, we have a lot of things that do not work well, because we have
44 usability issues that need to be preserved for hysterical raisins.
45 </p><p>
46 This is unfortunate enough, but it seems that we even fsck up with usability
48 typo? Yes, of course! But a rather obvious one.
49 </p><p>
50 Another case which was discussed on the mailing list recently: "git checkout
52 </p><p>
53 The biggest problem, though, is that almost all people on the Git mailing list
54 who are respected by the maintainer are obviously too detached from the user
56 about it, or even to allow others to do anything about it.
57 </p><p>
58 It almost seems as if the Git wizards do not want Git to become easier to
59 use, lest they lose their special status.
60 </p><p>
61 My biggest problem is that it seems that my input gets more and more ignored,
62 or perceived as some crazy ideas that will just go away (which is true, because
63 I am pretty happy about a day-job that keeps me more than just busy, so I do not
64 have time not fight windmills, let alone motiviation to do so).
65 </p><p>
66 Even when a real user comes along to chime in, he's just brushed off, by an
67 otherwise very polite maintainer.
68 </p><p>
69 I am not even sure if I want to continue sending my patches from my personal
70 tree upstream, because things get so frustrating, for little to show in return.]]></description>
71 </item>
72 <item>
77 <description><![CDATA[The dilemma of being correct
78 </p><p>
79 So I am opinionated. No news there. The problem of being opinionated, though,
80 is that people do not take you seriously even if you are correct.
81 </p><p>
82 For example, I vividly remember having had concerns about the Git wrapper
84 that our maintainer did not have such concerns and took Daniel's patch. I could
85 not find proof of my public comment quickly enough to add a link here, though.
86 </p><p>
87 Alas, there are serious problems with being correct:
88 </p><p>
89 <ol>
90 <li>If you're correct, you waste a lot of time trying to convince people (but
91 they ignore you nevertheless),
92 <li>Other people are regularly p*ssed off, especially when they find out
93 (or even worse, when it is pointed out to them) that they were wrong, and
95 </ol>
96 </p><p>
97 It is a lose-lose situation.
98 </p><p>
99 In the current context, I am pretty certain that the rev cache and the pack
100 index are so similar in nature that we'll find quite a few issues that we had
101 with one repeated with the other.
102 </p><p>
104 invariably means that they refuse to be convinced of anything disagreeing with
105 their opinion ☺ -- I will just shut up, and probably have one or two odd
106 feelings when it turns out I was right.]]></description>
107 </item>
108 <item>
113 <description><![CDATA[The GraphGUI project
114 </p><p>
115 After a few unfortunate delays (and some fortunate ones, just not for us), the
116 GraphGUI project finally takes off. A quick first glance:
117 </p><p>
118 <center><img src=dscho.git?a=blob_plain;hb=c33212b23b2b3e45c14403efe82cabb1cd53f6e3;f=basic-gui.jpg basic-gui.jpg></center>
119 </p><p>
120 The delays were a bit unnerving, but the student is really bright and still
121 has the chance to pull the project off.
122 </p><p>
123 Next plans are to show text, too, to invent a rudimentary layout engine that
125 </p><p>
126 After that, integration into JGit (this probably triggered the eGit/JGit
127 split).
128 </p><p>
129 And then we'll go wild!]]></description>
130 </item>
131 <item>
136 <description><![CDATA[Wasting way too much time on msysGit
137 </p><p>
138 I recently got into the bad habit of spending a large amount of my waking
139 hours working on msysGit, more than is really healthy for me.
140 </p><p>
141 For example, I spent the whole morning -- when I should have worked on a
142 very important day-job project -- on trying to fix issue 258, where
144 with cmd.exe.
145 </p><p>
146 This is reducing my Git time budget to negative numbers, so much so that I
150 </p><p>
151 Now, some people who tried to teach me some time management strongly
152 criticized me for ignoring their lessons, and unfortunately, I have to agree.
153 </p><p>
155 was after I stopped working on it last year. I started it, and I would like
156 it to grow, but too few people took care of the issue tracker, too few tried
157 to debug their problems themselves, too few submitted fixes.
158 </p><p>
159 I note, though, that there is a positive trend. But being the impatient person
160 I am ("2 seconds is my attention span") I tend to want the trend to be more
161 impressive.
162 </p><p>
163 Anyway, no work on msysGit for at least 4 days, that's what the doctor (me)
164 said...]]></description>
165 </item>
166 <item>
171 <description><![CDATA[Working on jgit diff
172 </p><p>
173 Shawn did so many useful things that I use on a daily basis that I felt really
175 implementation I wrote for JGit.
176 </p><p>
177 Alas, it appears that the thing turned out to be almost a complete rewrite, as
178 the original implementation walked the edit graph in a rather inefficient way.
179 </p><p>
180 A little background: Myers' algorithm to generate "an edit script" works on
183 the upper left corner to the lower right corner, containing only horizontal,
184 vertical or diagonal elements, where diagonal elements are only allowed when
185 the lines of both files agree at that point:
186 </p><p>
187 <pre>
188 H E L L O , W O R L D
189 ----
190 L \
191 ---
192 O \
193 ---
194 W \
195 --------
196 </pre>
197 </p><p>
199 </p><p>
200 Myers' idea is to develop forward and backward paths at the same time
201 (increasing the number of non-diagonal elements uniformly), storing
202 only the latest end points. Once the paths meet, divide and conquer.
203 </p><p>
205 reconstruct the shortest paths, alas, this takes way too much memory.
206 </p><p>
207 My first implementation did not remember start or end of the non-diagonal
208 parts, and had to recurse way more often than really necessary (in the end,
209 we will order the non-diagonal parts into horizontal and vertical parts
210 anyway, so start and end are sufficient).
211 </p><p>
214 </item>
215 <item>
220 <description><![CDATA[No time for Git
221 </p><p>
222 It is a shame, but most of my Git time budget is taken by msysGit these
223 days.
224 </p><p>
225 But at least msysGit is moving again; I'll probably write a Herald about
226 it.]]></description>
227 </item>
228 <item>
233 <description><![CDATA[How to recover from a hackathon
234 </p><p>
235 Phew, 2 crazy and fantastic weeks are behind me. But it takes its toll:
236 a weekend I was more offline than online.
237 </p><p>
238 Things that are important now: relax. sleep. take a walk. learn to sleep
239 more than 4 hours a night again. learn to watch a movie without thinking
240 about code. go for a run.
241 </p><p>
242 And after recovering, back to the rebase-i-p branch!]]></description>
243 </item>
244 <item>
250 </p><p>
253 </p><p>
254 There are a few things missing before I can start assembling a patch
255 series for submission:
256 </p><p>
257 <ul>
258 <li>I need to handle the commit parents which are outside of the rebased
259 ones properly. In other words, when a commit is picked whose parent is
260 not rebased, it needs to be rebased onto $ONTO.
261 <li>The patch which uses patch-id to generate DROPPED directly also tries to
262 consolidate the handling of DROPPED commits by putting them into REWRITTEN
263 instead of DROPPED, but that breaks the tests. So, this patch needs to be
264 split.
268 for those commands, and this will be an early patch series.
269 <li>Time. I need time, desperately. If my day job was not as exciting as it
270 is, I would have more time for Git. As it is, I have to budget my time so
271 that I get anything done at all.
272 </ul>
273 </p><p>
274 These issues have been postponed due to Steffen taking a well-deserved
275 vacation, which means that I have to act as msysGit maintainer again.
276 </p><p>
277 And this coming week, I will have other things to do in all likeliness, so
279 week. If not then, due to a heavy workload, it will be postponed to early
280 April.
281 </p><p>
283 </item>
284 <item>
289 <description><![CDATA[New Git for Windows version
290 </p><p>
291 Phew. That was quite a day, almost exclusively spent on finishing that
292 installer. The worst part: updating GCC seemed not to be such a good idea
293 after all...
294 </p><p>
296 non-standard, in the common way of Microsoft) if you want to print 64-bit
298 </p><p>
299 After upgrading to the new GCC, a lot of warnings appeared, complaining
302 </p><p>
303 Being the naive I am, I mistook that for a sign that we could finally go
304 more standards-compliant.
305 </p><p>
306 However, it only means that we have to live with the warnings for now, as
307 the C runtime provided on Windows still strongly disagrees with standards
308 (and it has to continue to do so, lest it break existing programs).
309 </p><p>
310 Sigh.
311 </p><p>
312 At least I have the feeling that I caught the most important bugs before
313 releasing.]]></description>
314 </item>
315 <item>
320 <description><![CDATA[Code reviews
321 </p><p>
322 It has been said that reviewing patches is a most thankless job. As I really
323 like the elegance of Git's source code, and care a lot about it, I did not
324 think that it was thankless, just a little bit tedious (especially when the
325 patch authors mistake criticism for personal attacks).
326 </p><p>
327 Usually, I am pretty good at ignoring insults as responses to my comments;
328 after all, I have a lot more enjoyable things to do than to spend time talking
329 to a guy who shows how wise he is when he thinks that I criticize him
331 my knowledge.
332 </p><p>
333 However, in the last days, three people really seemed to want to insult me,
334 to make me go away, to stop the fun I have with Git.
335 </p><p>
336 And they almost succeeded.
337 </p><p>
338 So I guess it is time to reassess my priorities, and maybe stop reviewing
339 Git patches altogether.]]></description>
340 </item>
341 </channel>
342 </rss>