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