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