?  search:
summary | log | graphiclog1 | graphiclog2 | commit | commitdiff | tree | refs | edit | fork
blame | history | raw | HEAD
Add a bookmark to snucode
[git/dscho.git] / index.html
blob0e1eb26aafd66a16571c49158ff27cf6919a6080
1 <html>
2 <head>
3 <title>Dscho's Git log</title>
4 <meta http-equiv="Content-Type"
5 content="text/html; charset=UTF-8"/>
6 </head>
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;;font-family: Arial, sans-serif;">
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>
13 <tr><td>
14 <p><ul>
15 <li><a href=#1289325547>09 Nov 2010 Fun brainstorm session about "Users' Git Helper", a potential new porcelain</a>
16 <li><a href=#1276255806>11 Jun 2010 New msysGit imminent</a>
17 <li><a href=#1265634257>08 Feb 2010 Trying to get more time for msysGit</a>
18 <li><a href=#1259765885>02 Dec 2009 Avoiding to get angry</a>
19 <li><a href=#1255867912>18 Oct 2009 Git will never be user-friendly</a>
20 <li><a href=#1254868748>07 Oct 2009 GitTogether in Berlin</a>
21 <li><a href=#1249835938>09 Aug 2009 The dilemma of being correct</a>
22 <li><a href=#1245419588>19 Jun 2009 The GraphGUI project</a>
23 <li><a href=#1242408298>15 May 2009 Wasting way too much time on msysGit</a>
24 <li><a href=#1241995759>11 May 2009 Working on jgit diff</a>
25 </ul></p>
26 <a href=dscho.git?a=blob_plain;hb=4b4d3a227b9e6acc34fd1e8a49b5b76dfbffdb68;f=index.html>Older posts</a>
27 </td></tr></table>
28 <br>
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>
34 </div>
35 <br>
36 <table width=400px bgcolor=#e0e0e0 border=0>
37 <tr><th>About this blog:</th></tr>
38 <tr><td>
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.
42 </p><p>
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.
45 </p><p>
46 This blog also serves to grace the world with Dscho's random thoughts on and
47 around Git.
48 </p>
49 </td></tr></table>
50 <br>
51 <table width=400px bgcolor=#e0e0e0 border=0>
52 <tr><th>Links:</th></tr>
53 <tr><td>
54 <ul>
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
62 than X</a> site
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.
71 </ul>
72 </td></tr></table>
73 <br>
74 <table width=400px bgcolor=#e0e0e0 border=0>
75 <tr><th>Google Ads:</th></tr>
76 <tr><td>
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;
83 //-->
84 </script>
85 <script type="text/javascript"
86 src="http://pagead2.googlesyndication.com/pagead/show_ads.js">
87 </script>
88 </td></tr></table>
89 </div>
90 <h6>Tuesday, 9th of November, Anno Domini MMX, at the hour of the Rooster</h6>
91 <a name=1289325547>
92 <h2>Fun brainstorm session about "Users' Git Helper", a potential new porcelain</h2>
93
94 <p>
95 </p><p>
96 In a not so serious Skype conversation, the issue of Git's usability came
97 up. Once again. It is a sad thing that still, the user interface design of
98 Git has nothing in common with the straight-forward, beautiful and simple
99 design of the data structures beneath.
100 </p><p>
101 It is still quite common for me to suggest using Subversion to other people
102 because it is easier to use.
103 </p><p>
104 So the idea was to have a new "porcelain" for Git, which would try much,
105 much harder to be intuitive than all the other porcelains which try to fix
106 the user interface warts of the Git command line interface.
107 </p><p>
108 In other words, the idea is that there is no way you can fix the command-line
109 interface, for a number of reasons, not the least of which is the inertia of
110 a precious few power-users, which according to <a href="http://developer.apple.com/library/mac/documentation/UserExperience/Conceptual/AppleHIGuidelines/XHIGIntro/XHIGIntro.html">Apple's Human Interface Guidelines</a> is not a good thing:
111 <a href="http://developer.apple.com/library/mac/documentation/UserExperience/Conceptual/AppleHIGuidelines/XHIGDesignProcess/XHIGDesignProcess.html#//apple_ref/doc/uid/TP40002718-TPXREF136">"If you try to design for the 20 percent of your target audience who are power users, your design may not be usable by the other 80 percent of users."</a>. Just as an example, what does splitting a mailbox into individual mails have to do with Version Control? Exactly.
112 </p><p>
113 Guiding principle would be the 80 percent solution, or analogously:
114 </p><p>
115 <ul>
116 <li> Optimize for the common case.
117 <li> Make the simple easy and the difficult possible.
118 <li> Before the green button, the Xerox machine was unusable.
119 </ul>
120 </p><p>
121 So many different ways to describe the same thing &#x263a;
122 </p><p>
123 But enough of the philosophical talk. Let's look at some possible interface design. First things first, the name. Users' Git Helper:
124 </p><p>
125 <table
126 border=1 bgcolor=black>
127 <tr><td bgcolor=lightblue colspan=3>
128 <pre> </pre>
129 </td></tr>
130 <tr><td>
131 <table cellspacing=5 border=0
132 style="color:white;">
133 <tr><td>
134 <pre>
135 ugh
136 </pre>
137 </td></tr>
138 </table>
139 </td></tr>
140 </table>
141 </p><p>
142 The first thing you usually want to do<sup><a name="ref-1" /><a href="#foot-1">1</a></sup>: get the project from somewhere:
143 </p><p>
144 <table
145 border=1 bgcolor=black>
146 <tr><td bgcolor=lightblue colspan=3>
147 <pre> </pre>
148 </td></tr>
149 <tr><td>
150 <table cellspacing=5 border=0
151 style="color:white;">
152 <tr><td>
153 <pre>
154 ugh get URL
155 </pre>
156 </td></tr>
157 </table>
158 </td></tr>
159 </table>
160 </p><p>
161 The next thing is probably that you want to look at what you got.
162 </p><p>
163 <table
164 border=1 bgcolor=black>
165 <tr><td bgcolor=lightblue colspan=3>
166 <pre> </pre>
167 </td></tr>
168 <tr><td>
169 <table cellspacing=5 border=0
170 style="color:white;">
171 <tr><td>
172 <pre>
173 ugh show [ANYTHING, INCLUDING COMMIT NAMES]
174 </pre>
175 </td></tr>
176 </table>
177 </td></tr>
178 </table>
179 </p><p>
180 It would default at showing the current commit, with the branch name and then
181 the abbreviated commit name in parentheses.
182 </p><p>
183 In general, no command would show the usage when called without options. That
184 is what
185 </p><p>
186 <table
187 border=1 bgcolor=black>
188 <tr><td bgcolor=lightblue colspan=3>
189 <pre> </pre>
190 </td></tr>
191 <tr><td>
192 <table cellspacing=5 border=0
193 style="color:white;">
194 <tr><td>
195 <pre>
196 ugh help COMMAND
197 </pre>
198 </td></tr>
199 </table>
200 </td></tr>
201 </table>
202 </p><p>
203 is for. And this command would not call 'man' to do the job. It would do the
204 job.
205 </p><p>
206 <table
207 border=1 bgcolor=black>
208 <tr><td bgcolor=lightblue colspan=3>
209 <pre> </pre>
210 </td></tr>
211 <tr><td>
212 <table cellspacing=5 border=0
213 style="color:white;">
214 <tr><td>
215 <pre>
216 ugh commit
217 </pre>
218 </td></tr>
219 </table>
220 </td></tr>
221 </table>
222 </p><p>
223 would have no options, as it tries to discover what is there, and lets the user
224 choose between options, most sensible ones first.
225 </p><p>
226 To share your work with others,
227 </p><p>
228 <table
229 border=1 bgcolor=black>
230 <tr><td bgcolor=lightblue colspan=3>
231 <pre> </pre>
232 </td></tr>
233 <tr><td>
234 <table cellspacing=5 border=0
235 style="color:white;">
236 <tr><td>
237 <pre>
238 ugh publish [REMOTE]
239 </pre>
240 </td></tr>
241 </table>
242 </td></tr>
243 </table>
244 </p><p>
245 would do that. The default remote would be the one from which you branched off.
246 </p><p>
247 Oh, and of course, there <a href="http://developer.apple.com/library/mac/documentation/UserExperience/Conceptual/AppleHIGuidelines/XHIGHIDesign/XHIGHIDesign.html#//apple_ref/doc/uid/TP30000353-TPXREF107">must be an undo</a>:
248 </p><p>
249 <table
250 border=1 bgcolor=black>
251 <tr><td bgcolor=lightblue colspan=3>
252 <pre> </pre>
253 </td></tr>
254 <tr><td>
255 <table cellspacing=5 border=0
256 style="color:white;">
257 <tr><td>
258 <pre>
259 ugh undo
260 </pre>
261 </td></tr>
262 </table>
263 </td></tr>
264 </table>
265 </p><p>
266 The 'undo' command must be intelligent about what makes sense and what not.
267 For example, once published, the commit should not be undoable, except on
268 another branch. And undoing a "publish" should not be possible, except if
269 the respective remote is marked as "personal", and the user should be told
270 how to set this conveniently.
271 </p><p>
272 Inside a repository, "ugh get" would try to pull the tracked branch if it
273 fast-forwards (but it would not say the word "fast-forward"; I had to explain
274 the meaning of that term one hundred billion times; one hundred billion times
275 too many, if you ask me), but fetch in any case and error out with the message
276 that there are local commits in addition to remote ones, so a merge is
277 necessary:
278 </p><p>
279 <table
280 border=1 bgcolor=black>
281 <tr><td bgcolor=lightblue colspan=3>
282 <pre> </pre>
283 </td></tr>
284 <tr><td>
285 <table cellspacing=5 border=0
286 style="color:white;">
287 <tr><td>
288 <pre>
289 ugh merge [REMOTE [BRANCH]]
290 </pre>
291 </td></tr>
292 </table>
293 </td></tr>
294 </table>
295 </p><p>
296 Since people are familiar with other commands, "ugh COMMAND --help" would be
297 an alias to "ugh help COMMAND". But it would not be advertised in the
298 documentation, because documentation is where you learn how the program is
299 intended to be used.
300 </p><p>
301 No rebase.
302 </p><p>
303 What is a "rebase"? What would you have answered in 2004? Me, too, I would have
304 said "dunno, tell me!".
305 </p><p>
306 So it is all about branches.
307 </p><p>
308 <table
309 border=1 bgcolor=black>
310 <tr><td bgcolor=lightblue colspan=3>
311 <pre> </pre>
312 </td></tr>
313 <tr><td>
314 <table cellspacing=5 border=0
315 style="color:white;">
316 <tr><td>
317 <pre>
318 ugh branches
319 </pre>
320 </td></tr>
321 </table>
322 </td></tr>
323 </table>
324 </p><p>
325 shows the branches. Make a new branch from the current state:
326 </p><p>
327 <table
328 border=1 bgcolor=black>
329 <tr><td bgcolor=lightblue colspan=3>
330 <pre> </pre>
331 </td></tr>
332 <tr><td>
333 <table cellspacing=5 border=0
334 style="color:white;">
335 <tr><td>
336 <pre>
337 ugh branch create BRANCH
338 </pre>
339 </td></tr>
340 </table>
341 </td></tr>
342 </table>
343 </p><p>
344 Make a new branch from another state:
345 </p><p>
346 <table
347 border=1 bgcolor=black>
348 <tr><td bgcolor=lightblue colspan=3>
349 <pre> </pre>
350 </td></tr>
351 <tr><td>
352 <table cellspacing=5 border=0
353 style="color:white;">
354 <tr><td>
355 <pre>
356 ugh branch create BRANCH from OTHER-BRANCH
357 </pre>
358 </td></tr>
359 </table>
360 </td></tr>
361 </table>
362 </p><p>
363 where the other branch can be a local or a remote one. If there are more than
364 one possibility, the command asks you.
365 </p><p>
366 If you want to know what "rebase" means, this is how it would be spelt out:
367 </p><p>
368 <table
369 border=1 bgcolor=black>
370 <tr><td bgcolor=lightblue colspan=3>
371 <pre> </pre>
372 </td></tr>
373 <tr><td>
374 <table cellspacing=5 border=0
375 style="color:white;">
376 <tr><td>
377 <pre>
378 ugh branch move onto BRANCH
379 </pre>
380 </td></tr>
381 </table>
382 </td></tr>
383 </table>
384 </p><p>
385 Or something else, if you can come up with a more sensible name.
386 </p><p>
387 Now, how to handle "backward compatibility"?
388 </p><p>
389 No backwards compatibility. Not needed. Old farts like me can always use
390 </p><p>
391 <table
392 border=1 bgcolor=black>
393 <tr><td bgcolor=lightblue colspan=3>
394 <pre> </pre>
395 </td></tr>
396 <tr><td>
397 <table cellspacing=5 border=0
398 style="color:white;">
399 <tr><td>
400 <pre>
401 git make --me --sad
402 </pre>
403 </td></tr>
404 </table>
405 </td></tr>
406 </table>
407 </p><p>
408 or even
409 </p><p>
410 <table
411 border=1 bgcolor=black>
412 <tr><td bgcolor=lightblue colspan=3>
413 <pre> </pre>
414 </td></tr>
415 <tr><td>
416 <table cellspacing=5 border=0
417 style="color:white;">
418 <tr><td>
419 <pre>
420 git make ME^..sad
421 </pre>
422 </td></tr>
423 </table>
424 </td></tr>
425 </table>
426 </p><p>
427 By the way, even the usability of the string "ugh" is thought through: if you
428 use just one hand to type it very quickly, you end up with the correct finger
429 in the end.
430 </p><p>
431 <h4>Footnotes</h4>
432 </p><p>
433 <a name="foot-1" /><a href="#ref-1">1</a>: In the olden days, there were no
434 repositories to get from somewhere, so it is obvious why the initial user
435 interface design did not make that easy. Now, you might think that a "git clone"
436 is not too bad, but why all these differences between "clone", "fetch", "pull"?
437 This is exactly the problem, because the technical details are different. The
438 very same details the users could not care less about. The very same details the
439 users should not <u>need</u> to care about.
440 </p>
441 <h6>Friday, 11th of June, Anno Domini MMX, at the hour of the Goat</h6>
442 <a name=1276255806>
443 <h2>New msysGit imminent</h2>
444
445 <p>
446 </p><p>
447 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.
448 </p>
449 <h6>Monday, 8th of February, Anno Domini MMX, at the hour of the Goat</h6>
450 <a name=1265634257>
451 <h2>Trying to get more time for msysGit</h2>
452
453 <p>
454 </p><p>
455 Nowadays, the msysGit project is driven forward mostly by Heiko Voigt,
456 Erik Faye-Lund, and of course the invaluable mingw.git work of Hannes
457 Sixt. The new-SVN, MinGW-SVN and MinGW-Python projects have stalled.
458 The latest msysGit release is <u>months</u> old.
459 </p><p>
460 It does not help that certain people on the Git mailing list write
461 looooong emails that nobody with my schedule can hope to read, rather
462 than being nice and spending some time to phrase what they have to
463 say in a <u>concise</u> manner.
464 </p><p>
465 Oh well. I will just concentrate on JGit and msysGit instead of
466 upstream Git, if I get some Git time.
467 </p>
468 <h6>Wednesday, 2nd of December, Anno Domini MMIX, at the hour of the Monkey</h6>
469 <a name=1259765885>
470 <h2>Avoiding to get angry</h2>
471
472 <p>
473 </p><p>
474 Despite many intelligent people realizing that the recent
475 change to special case http, https and ftp was a terrible decision, it
476 seems that there is enough resistance left on the Git mailing list to
477 keep the brain-dead current state.
478 </p><p>
479 The Git mailing list is definitely giving me more grief than joy these
480 days.
481 </p>
482 <h6>Sunday, 18th of October, Anno Domini MMIX, at the hour of the Goat</h6>
483 <a name=1255867912>
484 <h2>Git will never be user-friendly</h2>
485
486 <p>
487 </p><p>
488 Recently, encouraged by quite some private encouragement, I thought I could
489 take on the task of teaching the core Git developers how user-unfriendly
490 Git is, and that they should be more open to change (especially given that
491 1.7.0 was already announced to be a version that breaks recent expectations,
492 something I would have expected to merit a 2.0 -- but who am I anyway?).
493 </p><p>
494 It is quite ironic, in a very cruel sense, that those people who are such
495 big fans of educating the users instead of fixing their tools are unable
496 to be educated about something that should be obvious.
497 </p><p>
498 Yes, I am bitter.
499 </p>
500 <h6>Wednesday, 7th of October, Anno Domini MMIX, at the hour of the Rat</h6>
501 <a name=1254868748>
502 <h2>GitTogether in Berlin</h2>
503
504 <p>
505 </p><p>
506 We had a GitTogether in Berlin, called "Alles wird Git" (past tense: "Alles
507 wurde Git"). It was great fun, we never had even a single boring minute,
508 and our special guest -- Gitzilla -- turned out to be quite some entertainer,
509 especially when he starting reciting a few of my most outrageous emails &#x263a;
510 </p><p>
511 There were a lot of good discussions, among other things about submodules (our
512 neglected child), Git Cheetah, and foreign VCS helpers (in particular Sverre's
513 plan to provide some Mercurial backend).
514 </p><p>
515 One of the most important outcomes for me was, though, to realize just how
516 detached we in the Git project are from our user base. A few years back, we
517 could get away with saying "we have only developers as users, so they should
518 just sit down and scratch their own itch".
519 </p><p>
520 But today, we have a lot of users who never learnt to code (or who code in
521 some other language than C, or whose code we would not even want to review &#x263a;),
522 and we lose quite a few brownie points by keeping things complicated.
523 </p><p>
524 Now, in a lot of cases it cannot be helped. For example, we have confusing
525 names for things, inconsistent namings even (as with "remote" vs "tracked"
526 branches), and we have some odd design decisions (like calling some program
527 almost nobody uses "git cherry", which makes tab-completion of the rather
528 often-used "git cherry-pick" pretty awkward). The latter example also
529 illustrates that we have names for porcelains that are rather long, when
530 they should be rather short.
531 </p><p>
532 So, yes, we have a lot of things that do not work well, because we have
533 usability issues that need to be preserved for hysterical raisins.
534 </p><p>
535 This is unfortunate enough, but it seems that we even fsck up with usability
536 issues we <u>can</u> solve. Just think about "git checkout -b origin/master". A
537 typo? Yes, of course! But a rather obvious one.
538 </p><p>
539 Another case which was discussed on the mailing list recently: "git checkout
540 next" when clearly "git checkout origin/next" was meant.
541 </p><p>
542 The biggest problem, though, is that almost all people on the Git mailing list
543 who are respected by the maintainer are obviously too detached from the user
544 base to realize just how difficult Git <u>still</u> is. And refuse to do anything
545 about it, or even to allow others to do anything about it.
546 </p><p>
547 It almost seems as if the Git wizards do not want Git to become easier to
548 use, lest they lose their special status.
549 </p><p>
550 My biggest problem is that it seems that my input gets more and more ignored,
551 or perceived as some crazy ideas that will just go away (which is true, because
552 I am pretty happy about a day-job that keeps me more than just busy, so I do not
553 have time not fight windmills, let alone motiviation to do so).
554 </p><p>
555 Even when a real user comes along to chime in, he's just brushed off, by an
556 otherwise very polite maintainer.
557 </p><p>
558 I am not even sure if I want to continue sending my patches from my personal
559 tree upstream, because things get so frustrating, for little to show in return.
560 </p>
561 <h6>Sunday, 9th of August, Anno Domini MMIX, at the hour of the Rooster</h6>
562 <a name=1249835938>
563 <h2>The dilemma of being correct</h2>
564
565 <p>
566 </p><p>
567 So I am opinionated. No news there. The problem of being opinionated, though,
568 is that people do not take you seriously even if you are correct.
569 </p><p>
570 For example, I vividly remember having had concerns about the Git wrapper
571 being linked to <a href=http://curl.haxx.se/>cURL</a>, and I vividly remember
572 that our maintainer did not have such concerns and took Daniel's patch. I could
573 not find proof of my public comment quickly enough to add a link here, though.
574 </p><p>
575 Alas, there are serious problems with being correct:
576 </p><p>
577 <ol>
578 <li>If you're correct, you waste a lot of time trying to convince people (but
579 they ignore you nevertheless),
580 <li>Other people are regularly p*ssed off, especially when they find out
581 (or even worse, when it is pointed out to them) that they were wrong, and
582 <li>You can buy <u>nothing</u> for having been correct.
583 </ol>
584 </p><p>
585 It is a lose-lose situation.
586 </p><p>
587 In the current context, I am pretty certain that the rev cache and the pack
588 index are so similar in nature that we'll find quite a few issues that we had
589 with one repeated with the other.
590 </p><p>
591 As I <u>hate</u> losing time over a discussion others try to "win" -- which
592 invariably means that they refuse to be convinced of anything disagreeing with
593 their opinion &#x263a; -- I will just shut up, and probably have one or two odd
594 feelings when it turns out I was right.
595 </p>
596 <h6>Friday, 19th of June, Anno Domini MMIX, at the hour of the Monkey</h6>
597 <a name=1245419588>
598 <h2>The GraphGUI project</h2>
599
600 <p>
601 </p><p>
602 After a few unfortunate delays (and some fortunate ones, just not for us), the
603 GraphGUI project finally takes off. A quick first glance:
604 </p><p>
605 <center><img src=dscho.git?a=blob_plain;hb=c33212b23b2b3e45c14403efe82cabb1cd53f6e3;f=basic-gui.jpg basic-gui.jpg></center>
606 </p><p>
607 The delays were a bit unnerving, but the student is really bright and still
608 has the chance to pull the project off.
609 </p><p>
610 Next plans are to show text, too, to invent a rudimentary layout engine that
611 can be adjusted manually (this is in contrast to <i>gitk</i> or <i>log --graph</i>).
612 </p><p>
613 After that, integration into JGit (this probably triggered the eGit/JGit
614 split).
615 </p><p>
616 And then we'll go wild!
617 </p>
618 <h6>Friday, 15th of May, Anno Domini MMIX, at the hour of the Dog</h6>
619 <a name=1242408298>
620 <h2>Wasting way too much time on msysGit</h2>
621
622 <p>
623 </p><p>
624 I recently got into the bad habit of spending a large amount of my waking
625 hours working on msysGit, more than is really healthy for me.
626 </p><p>
627 For example, I spent the whole morning -- when I should have worked on a
628 very important day-job project -- on trying to fix issue 258, where
629 <i>git web--browse</i> does not work as expected because of quoting issues
630 with cmd.exe.
631 </p><p>
632 This is reducing my Git time budget to negative numbers, so much so that I
633 cannot even work on Git projects that I actually like, such as <i>jgit diff</i>
634 or <i>git rebase -i -p</i>, or at least projects I felt obliged to continue
635 to work on, such as <i>git notes</i>.
636 </p><p>
637 Now, some people who tried to teach me some time management strongly
638 criticized me for ignoring their lessons, and unfortunately, I have to agree.
639 </p><p>
640 The problem is that I would <u>hate</u> to see msysGit fall to the same state it
641 was after I stopped working on it last year. I started it, and I would like
642 it to grow, but too few people took care of the issue tracker, too few tried
643 to debug their problems themselves, too few submitted fixes.
644 </p><p>
645 I note, though, that there is a positive trend. But being the impatient person
646 I am ("2 seconds is my attention span") I tend to want the trend to be more
647 impressive.
648 </p><p>
649 Anyway, no work on msysGit for at least 4 days, that's what the doctor (me)
650 said...
651 </p>
652 <h6>Monday, 11th of May, Anno Domini MMIX, at the hour of the Rat</h6>
653 <a name=1241995759>
654 <h2>Working on jgit diff</h2>
655
656 <p>
657 </p><p>
658 Shawn did so many useful things that I use on a daily basis that I felt really
659 awful when I realized just how <u>long</u> I had promised to clean up that diff
660 implementation I wrote for JGit.
661 </p><p>
662 Alas, it appears that the thing turned out to be almost a complete rewrite, as
663 the original implementation walked the edit graph in a rather inefficient way.
664 </p><p>
665 A little background: Myers' algorithm to generate "an edit script" works on
666 the <i>edit graph</i>: imagine you have all lines of file <i>A</i> as columns and
667 all lines of file <i>B</i> as rows, then the <i>edit graph</i> is a connection of
668 the upper left corner to the lower right corner, containing only horizontal,
669 vertical or diagonal elements, where diagonal elements are only allowed when
670 the lines of both files agree at that point:
671 </p><p>
672 <pre>
673 H E L L O , W O R L D
674 ----
675 L \
676 ---
677 O \
678 ---
679 W \
680 --------
681 </pre>
682 </p><p>
683 The <i>shortest</i> edit path minimizes the number of non-diagonal elements.
684 </p><p>
685 Myers' idea is to develop forward and backward paths at the same time
686 (increasing the number of non-diagonal elements uniformly), storing
687 only the latest end points. Once the paths meet, divide and conquer.
688 </p><p>
689 In theory, it would be quicker to store <u>all</u> end points and then just
690 reconstruct the shortest paths, alas, this takes way too much memory.
691 </p><p>
692 My first implementation did not remember start or end of the non-diagonal
693 parts, and had to recurse way more often than really necessary (in the end,
694 we will order the non-diagonal parts into horizontal and vertical parts
695 anyway, so start and end are sufficient).
696 </p><p>
697 The current progress can be seen <a href=http://repo.or.cz/w/egit/dscho.git/>
698 here</a>.
699 </p>
700 </div>
701 </body>
702 </html>
Dscho's miscellaneous git branches