| blob | 605b1e0c8f1a212d85de8be6f7e526f2ac32f571 |
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[Avoiding to get angry
16 </p><p>
17 It seems that despite many intelligent people realizing that the recent
18 change to special case http, https and ftp was a terrible decision, it
19 seems that there is enough resistance left on the Git mailing list to
20 keep the brain-dead current state.
21 </p><p>
22 The Git mailing list is definitely giving me more grief than joy these
23 days.]]></description>
24 </item>
25 <item>
30 <description><![CDATA[Git will never be user-friendly
31 </p><p>
32 Recently, encouraged by quite some private encouragement, I thought I could
33 take on the task of teaching the core Git developers how user-unfriendly
34 Git is, and that they should be more open to change (especially given that
35 1.7.0 was already announced to be a version that breaks recent expectations,
36 something I would have expected to merit a 2.0 -- but who am I anyway?).
37 </p><p>
38 It is quite ironic, in a very cruel sense, that those people who are such
39 big fans of educating the users instead of fixing their tools are unable
40 to be educated about something that should be obvious.
41 </p><p>
42 Yes, I am bitter.]]></description>
43 </item>
44 <item>
49 <description><![CDATA[GitTogether in Berlin
50 </p><p>
52 wurde Git"). It was great fun, we never had even a single boring minute,
53 and our special guest -- Gitzilla -- turned out to be quite some entertainer,
54 especially when he starting reciting a few of my most outrageous emails ☺
55 </p><p>
56 There were a lot of good discussions, among other things about submodules (our
57 neglected child), Git Cheetah, and foreign VCS helpers (in particular Sverre's
58 plan to provide some Mercurial backend).
59 </p><p>
60 One of the most important outcomes for me was, though, to realize just how
61 detached we in the Git project are from our user base. A few years back, we
62 could get away with saying "we have only developers as users, so they should
63 just sit down and scratch their own itch".
64 </p><p>
65 But today, we have a lot of users who never learnt to code (or who code in
66 some other language than C, or whose code we would not even want to review ☺),
67 and we lose quite a few brownie points by keeping things complicated.
68 </p><p>
69 Now, in a lot of cases it cannot be helped. For example, we have confusing
71 branches), and we have some odd design decisions (like calling some program
72 almost nobody uses "git cherry", which makes tab-completion of the rather
73 often-used "git cherry-pick" pretty awkward). The latter example also
74 illustrates that we have names for porcelains that are rather long, when
75 they should be rather short.
76 </p><p>
77 So, yes, we have a lot of things that do not work well, because we have
78 usability issues that need to be preserved for hysterical raisins.
79 </p><p>
80 This is unfortunate enough, but it seems that we even fsck up with usability
82 typo? Yes, of course! But a rather obvious one.
83 </p><p>
84 Another case which was discussed on the mailing list recently: "git checkout
86 </p><p>
87 The biggest problem, though, is that almost all people on the Git mailing list
88 who are respected by the maintainer are obviously too detached from the user
90 about it, or even to allow others to do anything about it.
91 </p><p>
92 It almost seems as if the Git wizards do not want Git to become easier to
93 use, lest they lose their special status.
94 </p><p>
95 My biggest problem is that it seems that my input gets more and more ignored,
96 or perceived as some crazy ideas that will just go away (which is true, because
97 I am pretty happy about a day-job that keeps me more than just busy, so I do not
98 have time not fight windmills, let alone motiviation to do so).
99 </p><p>
100 Even when a real user comes along to chime in, he's just brushed off, by an
101 otherwise very polite maintainer.
102 </p><p>
103 I am not even sure if I want to continue sending my patches from my personal
104 tree upstream, because things get so frustrating, for little to show in return.]]></description>
105 </item>
106 <item>
111 <description><![CDATA[The dilemma of being correct
112 </p><p>
113 So I am opinionated. No news there. The problem of being opinionated, though,
114 is that people do not take you seriously even if you are correct.
115 </p><p>
116 For example, I vividly remember having had concerns about the Git wrapper
118 that our maintainer did not have such concerns and took Daniel's patch. I could
119 not find proof of my public comment quickly enough to add a link here, though.
120 </p><p>
121 Alas, there are serious problems with being correct:
122 </p><p>
123 <ol>
124 <li>If you're correct, you waste a lot of time trying to convince people (but
125 they ignore you nevertheless),
126 <li>Other people are regularly p*ssed off, especially when they find out
127 (or even worse, when it is pointed out to them) that they were wrong, and
129 </ol>
130 </p><p>
131 It is a lose-lose situation.
132 </p><p>
133 In the current context, I am pretty certain that the rev cache and the pack
134 index are so similar in nature that we'll find quite a few issues that we had
135 with one repeated with the other.
136 </p><p>
138 invariably means that they refuse to be convinced of anything disagreeing with
139 their opinion ☺ -- I will just shut up, and probably have one or two odd
140 feelings when it turns out I was right.]]></description>
141 </item>
142 <item>
147 <description><![CDATA[The GraphGUI project
148 </p><p>
149 After a few unfortunate delays (and some fortunate ones, just not for us), the
150 GraphGUI project finally takes off. A quick first glance:
151 </p><p>
152 <center><img src=dscho.git?a=blob_plain;hb=c33212b23b2b3e45c14403efe82cabb1cd53f6e3;f=basic-gui.jpg basic-gui.jpg></center>
153 </p><p>
154 The delays were a bit unnerving, but the student is really bright and still
155 has the chance to pull the project off.
156 </p><p>
157 Next plans are to show text, too, to invent a rudimentary layout engine that
159 </p><p>
160 After that, integration into JGit (this probably triggered the eGit/JGit
161 split).
162 </p><p>
163 And then we'll go wild!]]></description>
164 </item>
165 <item>
170 <description><![CDATA[Wasting way too much time on msysGit
171 </p><p>
172 I recently got into the bad habit of spending a large amount of my waking
173 hours working on msysGit, more than is really healthy for me.
174 </p><p>
175 For example, I spent the whole morning -- when I should have worked on a
176 very important day-job project -- on trying to fix issue 258, where
178 with cmd.exe.
179 </p><p>
180 This is reducing my Git time budget to negative numbers, so much so that I
184 </p><p>
185 Now, some people who tried to teach me some time management strongly
186 criticized me for ignoring their lessons, and unfortunately, I have to agree.
187 </p><p>
189 was after I stopped working on it last year. I started it, and I would like
190 it to grow, but too few people took care of the issue tracker, too few tried
191 to debug their problems themselves, too few submitted fixes.
192 </p><p>
193 I note, though, that there is a positive trend. But being the impatient person
194 I am ("2 seconds is my attention span") I tend to want the trend to be more
195 impressive.
196 </p><p>
197 Anyway, no work on msysGit for at least 4 days, that's what the doctor (me)
198 said...]]></description>
199 </item>
200 <item>
205 <description><![CDATA[Working on jgit diff
206 </p><p>
207 Shawn did so many useful things that I use on a daily basis that I felt really
209 implementation I wrote for JGit.
210 </p><p>
211 Alas, it appears that the thing turned out to be almost a complete rewrite, as
212 the original implementation walked the edit graph in a rather inefficient way.
213 </p><p>
214 A little background: Myers' algorithm to generate "an edit script" works on
217 the upper left corner to the lower right corner, containing only horizontal,
218 vertical or diagonal elements, where diagonal elements are only allowed when
219 the lines of both files agree at that point:
220 </p><p>
221 <pre>
222 H E L L O , W O R L D
223 ----
224 L \
225 ---
226 O \
227 ---
228 W \
229 --------
230 </pre>
231 </p><p>
233 </p><p>
234 Myers' idea is to develop forward and backward paths at the same time
235 (increasing the number of non-diagonal elements uniformly), storing
236 only the latest end points. Once the paths meet, divide and conquer.
237 </p><p>
239 reconstruct the shortest paths, alas, this takes way too much memory.
240 </p><p>
241 My first implementation did not remember start or end of the non-diagonal
242 parts, and had to recurse way more often than really necessary (in the end,
243 we will order the non-diagonal parts into horizontal and vertical parts
244 anyway, so start and end are sufficient).
245 </p><p>
248 </item>
249 <item>
254 <description><![CDATA[No time for Git
255 </p><p>
256 It is a shame, but most of my Git time budget is taken by msysGit these
257 days.
258 </p><p>
259 But at least msysGit is moving again; I'll probably write a Herald about
260 it.]]></description>
261 </item>
262 <item>
267 <description><![CDATA[How to recover from a hackathon
268 </p><p>
269 Phew, 2 crazy and fantastic weeks are behind me. But it takes its toll:
270 a weekend I was more offline than online.
271 </p><p>
272 Things that are important now: relax. sleep. take a walk. learn to sleep
273 more than 4 hours a night again. learn to watch a movie without thinking
274 about code. go for a run.
275 </p><p>
276 And after recovering, back to the rebase-i-p branch!]]></description>
277 </item>
278 <item>
284 </p><p>
287 </p><p>
288 There are a few things missing before I can start assembling a patch
289 series for submission:
290 </p><p>
291 <ul>
292 <li>I need to handle the commit parents which are outside of the rebased
293 ones properly. In other words, when a commit is picked whose parent is
294 not rebased, it needs to be rebased onto $ONTO.
295 <li>The patch which uses patch-id to generate DROPPED directly also tries to
296 consolidate the handling of DROPPED commits by putting them into REWRITTEN
297 instead of DROPPED, but that breaks the tests. So, this patch needs to be
298 split.
302 for those commands, and this will be an early patch series.
303 <li>Time. I need time, desperately. If my day job was not as exciting as it
304 is, I would have more time for Git. As it is, I have to budget my time so
305 that I get anything done at all.
306 </ul>
307 </p><p>
308 These issues have been postponed due to Steffen taking a well-deserved
309 vacation, which means that I have to act as msysGit maintainer again.
310 </p><p>
311 And this coming week, I will have other things to do in all likeliness, so
313 week. If not then, due to a heavy workload, it will be postponed to early
314 April.
315 </p><p>
317 </item>
318 </channel>
319 </rss>