3 <title>Dscho's git log
</title>
4 <meta http-equiv=
"Content-Type"
5 content=
"text/html; charset=UTF-8"/>
7 <body style=
"width:800px;background-image:url(dscho.git?a=blob_plain;hb=c33212b23b2b3e45c14403efe82cabb1cd53f6e3;f=paper.jpg);background-repeat:repeat-y;background-attachment:scroll;padding:0px;">
8 <div style=
"width:610px;margin-left:120px;margin-top:50px;align:left;vertical-align:top;">
9 <h1>Dscho's git log
</h1>
10 <div style=
"position:absolute;top:50px;left:810px;width=400px">
11 <table width=
400px bgcolor=#e0e0e0 border=
0>
12 <tr><th>Table of contents:
</th></tr>
15 <li><a href=#
1276255806>11 Jun
2010 New msysGit imminent
</a>
16 <li><a href=#
1265634257>08 Feb
2010 Trying to get more time for msysGit
</a>
17 <li><a href=#
1259765885>02 Dec
2009 Avoiding to get angry
</a>
18 <li><a href=#
1255867912>18 Oct
2009 Git will never be user-friendly
</a>
19 <li><a href=#
1254868748>07 Oct
2009 GitTogether in Berlin
</a>
20 <li><a href=#
1249835938>09 Aug
2009 The dilemma of being correct
</a>
21 <li><a href=#
1245419588>19 Jun
2009 The GraphGUI project
</a>
22 <li><a href=#
1242408298>15 May
2009 Wasting way too much time on msysGit
</a>
23 <li><a href=#
1241995759>11 May
2009 Working on jgit diff
</a>
24 <li><a href=#
1239975597>17 Apr
2009 No time for Git
</a>
26 <a href=dscho.git?a=blob_plain;hb=bcbae592bcf8e15fb4a1a7fdf96f942732e7db92;f=index.html
>Older posts
</a>
29 <div style=
"text-align:right;">
30 <a href=
"dscho.git?a=blob_plain;hb=blog;f=blog.rss"
31 title=
"Subscribe to my RSS feed"
32 class=
"rss" rel=
"nofollow"
33 style=
"background-color:orange;text-decoration:none;color:white;font-family:sans-serif;">RSS
</a>
36 <table width=
400px bgcolor=#e0e0e0 border=
0>
37 <tr><th>About this blog:
</th></tr>
39 <p>It is an active
<a href=http://repo.or.cz/w/git/dscho.git?a=blob_plain;f=index.html;hb=
5f002cab57a837125a8f901bcd1f3c1477bc3119
>abuse
</a> of
<a href=http://repo.or.cz
/>repo.or.cz
</a>,
40 letting gitweb unpack the objects in the current tip of the branch
<i>blog
</i>,
41 including the images and the RSS feed.
43 Publishing means running a script that collects the posts, turns them into
44 HTML, makes sure all the images are checked in, and pushes the result.
46 This blog also serves to grace the world with Dscho's random thoughts on and
51 <table width=
400px bgcolor=#e0e0e0 border=
0>
52 <tr><th>Links:
</th></tr>
55 <li> <a href=http://git-scm.com
/>Git's homepage
</a>
56 <li> <a href=http://gitster.livejournal.com
/>Junio's blog
</a>
57 <li> <a href=http://www.spearce.org
/>Shawn's blog
</a> seems to be sitting
58 idle ever since he started working for Google...
59 <li> <a href=http://torvalds-family.blogspot.com
/>Linus' blog
</a> does not
60 talk much about Git...
61 <li> Scott Chacon's
<a href=http://whygitisbetterthanx.com
/>Why Git is better
63 <li> <a href=http://vilain.net
/>The blog of mugwump
</a>
64 <li> <a href=http://merlyn.vox.com
/>Merlyn's blog
</a>
65 <li> <a href=http://blogs.gnome.org/newren
/>Elijah Newren
</a> chose the
66 same path as Cogito, offering an alternative porcelain (an approach
67 that is doomed in my opinion)
68 <li> <a href=http://msysgit.googlecode.com
/>The msysGit project
</a>, a (mostly)
69 failed experiment to lure the many Windows developers out there to
70 contribute to Open Source for a change.
74 <table width=
400px bgcolor=#e0e0e0 border=
0>
75 <tr><th>Google Ads:
</th></tr>
77 <script type=
"text/javascript"><!--
78 google_ad_client
= "pub-5106407705643819";
79 /* 300x250, created 1/22/09 */
80 google_ad_slot
= "6468207338";
81 google_ad_width
= 300;
82 google_ad_height
= 250;
85 <script type=
"text/javascript"
86 src=
"http://pagead2.googlesyndication.com/pagead/show_ads.js">
90 <h6>Friday,
11th of June, Anno Domini MMX, at the hour of the Goat
</h6>
92 <h2>New msysGit imminent
</h2>
96 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.
98 <h6>Monday,
8th of February, Anno Domini MMX, at the hour of the Goat
</h6>
100 <h2>Trying to get more time for msysGit
</h2>
104 Nowadays, the msysGit project is driven forward mostly by Heiko Voigt,
105 Erik Faye-Lund, and of course the invaluable mingw.git work of Hannes
106 Sixt. The new-SVN, MinGW-SVN and MinGW-Python projects have stalled.
107 The latest msysGit release is
<u>months
</u> old.
109 It does not help that certain people on the Git mailing list write
110 looooong emails that nobody with my schedule can hope to read, rather
111 than being nice and spending some time to phrase what they have to
112 say in a
<u>concise
</u> manner.
114 Oh well. I will just concentrate on JGit and msysGit instead of
115 upstream Git, if I get some Git time.
117 <h6>Wednesday,
2nd of December, Anno Domini MMIX, at the hour of the Monkey
</h6>
119 <h2>Avoiding to get angry
</h2>
123 Despite many intelligent people realizing that the recent
124 change to special case http, https and ftp was a terrible decision, it
125 seems that there is enough resistance left on the Git mailing list to
126 keep the brain-dead current state.
128 The Git mailing list is definitely giving me more grief than joy these
131 <h6>Sunday,
18th of October, Anno Domini MMIX, at the hour of the Goat
</h6>
133 <h2>Git will never be user-friendly
</h2>
137 Recently, encouraged by quite some private encouragement, I thought I could
138 take on the task of teaching the core Git developers how user-unfriendly
139 Git is, and that they should be more open to change (especially given that
140 1.7.0 was already announced to be a version that breaks recent expectations,
141 something I would have expected to merit a
2.0 -- but who am I anyway?).
143 It is quite ironic, in a very cruel sense, that those people who are such
144 big fans of educating the users instead of fixing their tools are unable
145 to be educated about something that should be obvious.
149 <h6>Wednesday,
7th of October, Anno Domini MMIX, at the hour of the Rat
</h6>
151 <h2>GitTogether in Berlin
</h2>
155 We had a GitTogether in Berlin, called
"Alles wird Git" (past tense:
"Alles
156 wurde Git"). It was great fun, we never had even a single boring minute,
157 and our special guest -- Gitzilla -- turned out to be quite some entertainer,
158 especially when he starting reciting a few of my most outrageous emails
☺
160 There were a lot of good discussions, among other things about submodules (our
161 neglected child), Git Cheetah, and foreign VCS helpers (in particular Sverre's
162 plan to provide some Mercurial backend).
164 One of the most important outcomes for me was, though, to realize just how
165 detached we in the Git project are from our user base. A few years back, we
166 could get away with saying
"we have only developers as users, so they should
167 just sit down and scratch their own itch".
169 But today, we have a lot of users who never learnt to code (or who code in
170 some other language than C, or whose code we would not even want to review
☺),
171 and we lose quite a few brownie points by keeping things complicated.
173 Now, in a lot of cases it cannot be helped. For example, we have confusing
174 names for things, inconsistent namings even (as with
"remote" vs
"tracked"
175 branches), and we have some odd design decisions (like calling some program
176 almost nobody uses
"git cherry", which makes tab-completion of the rather
177 often-used
"git cherry-pick" pretty awkward). The latter example also
178 illustrates that we have names for porcelains that are rather long, when
179 they should be rather short.
181 So, yes, we have a lot of things that do not work well, because we have
182 usability issues that need to be preserved for hysterical raisins.
184 This is unfortunate enough, but it seems that we even fsck up with usability
185 issues we
<u>can
</u> solve. Just think about
"git checkout -b origin/master". A
186 typo? Yes, of course! But a rather obvious one.
188 Another case which was discussed on the mailing list recently:
"git checkout
189 next" when clearly
"git checkout origin/next" was meant.
191 The biggest problem, though, is that almost all people on the Git mailing list
192 who are respected by the maintainer are obviously too detached from the user
193 base to realize just how difficult Git
<u>still
</u> is. And refuse to do anything
194 about it, or even to allow others to do anything about it.
196 It almost seems as if the Git wizards do not want Git to become easier to
197 use, lest they lose their special status.
199 My biggest problem is that it seems that my input gets more and more ignored,
200 or perceived as some crazy ideas that will just go away (which is true, because
201 I am pretty happy about a day-job that keeps me more than just busy, so I do not
202 have time not fight windmills, let alone motiviation to do so).
204 Even when a real user comes along to chime in, he's just brushed off, by an
205 otherwise very polite maintainer.
207 I am not even sure if I want to continue sending my patches from my personal
208 tree upstream, because things get so frustrating, for little to show in return.
210 <h6>Sunday,
9th of August, Anno Domini MMIX, at the hour of the Rooster
</h6>
212 <h2>The dilemma of being correct
</h2>
216 So I am opinionated. No news there. The problem of being opinionated, though,
217 is that people do not take you seriously even if you are correct.
219 For example, I vividly remember having had concerns about the Git wrapper
220 being linked to
<a href=http://curl.haxx.se
/>cURL
</a>, and I vividly remember
221 that our maintainer did not have such concerns and took Daniel's patch. I could
222 not find proof of my public comment quickly enough to add a link here, though.
224 Alas, there are serious problems with being correct:
227 <li>If you're correct, you waste a lot of time trying to convince people (but
228 they ignore you nevertheless),
229 <li>Other people are regularly p*ssed off, especially when they find out
230 (or even worse, when it is pointed out to them) that they were wrong, and
231 <li>You can buy
<u>nothing
</u> for having been correct.
234 It is a lose-lose situation.
236 In the current context, I am pretty certain that the rev cache and the pack
237 index are so similar in nature that we'll find quite a few issues that we had
238 with one repeated with the other.
240 As I
<u>hate
</u> losing time over a discussion others try to
"win" -- which
241 invariably means that they refuse to be convinced of anything disagreeing with
242 their opinion
☺ -- I will just shut up, and probably have one or two odd
243 feelings when it turns out I was right.
245 <h6>Friday,
19th of June, Anno Domini MMIX, at the hour of the Monkey
</h6>
247 <h2>The GraphGUI project
</h2>
251 After a few unfortunate delays (and some fortunate ones, just not for us), the
252 GraphGUI project finally takes off. A quick first glance:
254 <center><img src=dscho.git?a=blob_plain;hb=c33212b23b2b3e45c14403efe82cabb1cd53f6e3;f=basic-gui.jpg basic-gui.jpg
></center>
256 The delays were a bit unnerving, but the student is really bright and still
257 has the chance to pull the project off.
259 Next plans are to show text, too, to invent a rudimentary layout engine that
260 can be adjusted manually (this is in contrast to
<i>gitk
</i> or
<i>log --graph
</i>).
262 After that, integration into JGit (this probably triggered the eGit/JGit
265 And then we'll go wild!
267 <h6>Friday,
15th of May, Anno Domini MMIX, at the hour of the Dog
</h6>
269 <h2>Wasting way too much time on msysGit
</h2>
273 I recently got into the bad habit of spending a large amount of my waking
274 hours working on msysGit, more than is really healthy for me.
276 For example, I spent the whole morning -- when I should have worked on a
277 very important day-job project -- on trying to fix issue
258, where
278 <i>git web--browse
</i> does not work as expected because of quoting issues
281 This is reducing my Git time budget to negative numbers, so much so that I
282 cannot even work on Git projects that I actually like, such as
<i>jgit diff
</i>
283 or
<i>git rebase -i -p
</i>, or at least projects I felt obliged to continue
284 to work on, such as
<i>git notes
</i>.
286 Now, some people who tried to teach me some time management strongly
287 criticized me for ignoring their lessons, and unfortunately, I have to agree.
289 The problem is that I would
<u>hate
</u> to see msysGit fall to the same state it
290 was after I stopped working on it last year. I started it, and I would like
291 it to grow, but too few people took care of the issue tracker, too few tried
292 to debug their problems themselves, too few submitted fixes.
294 I note, though, that there is a positive trend. But being the impatient person
295 I am (
"2 seconds is my attention span") I tend to want the trend to be more
298 Anyway, no work on msysGit for at least
4 days, that's what the doctor (me)
301 <h6>Monday,
11th of May, Anno Domini MMIX, at the hour of the Rat
</h6>
303 <h2>Working on jgit diff
</h2>
307 Shawn did so many useful things that I use on a daily basis that I felt really
308 awful when I realized just how
<u>long
</u> I had promised to clean up that diff
309 implementation I wrote for JGit.
311 Alas, it appears that the thing turned out to be almost a complete rewrite, as
312 the original implementation walked the edit graph in a rather inefficient way.
314 A little background: Myers' algorithm to generate
"an edit script" works on
315 the
<i>edit graph
</i>: imagine you have all lines of file
<i>A
</i> as columns and
316 all lines of file
<i>B
</i> as rows, then the
<i>edit graph
</i> is a connection of
317 the upper left corner to the lower right corner, containing only horizontal,
318 vertical or diagonal elements, where diagonal elements are only allowed when
319 the lines of both files agree at that point:
322 H E L L O , W O R L D
332 The
<i>shortest
</i> edit path minimizes the number of non-diagonal elements.
334 Myers' idea is to develop forward and backward paths at the same time
335 (increasing the number of non-diagonal elements uniformly), storing
336 only the latest end points. Once the paths meet, divide and conquer.
338 In theory, it would be quicker to store
<u>all
</u> end points and then just
339 reconstruct the shortest paths, alas, this takes way too much memory.
341 My first implementation did not remember start or end of the non-diagonal
342 parts, and had to recurse way more often than really necessary (in the end,
343 we will order the non-diagonal parts into horizontal and vertical parts
344 anyway, so start and end are sufficient).
346 The current progress can be seen
<a href=http://repo.or.cz/w/egit/dscho.git
/>
349 <h6>Friday,
17th of April, Anno Domini MMIX, at the hour of the Monkey
</h6>
351 <h2>No time for Git
</h2>
355 It is a shame, but most of my Git time budget is taken by msysGit these
358 But at least msysGit is moving again; I'll probably write a Herald about