?  search:
summary | log | graphiclog1 | graphiclog2 | commit | commitdiff | tree | refs | edit | fork
blame | history | raw | HEAD
Housekeeping on Tuesday, 9th of November, Anno Domini MMX, at the hour of the Dog
[git/dscho.git] / index.html
blob2177ed0f393e3f04166b1469d9471b2adaf993d1
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 branch
319 </pre>
320 </td></tr>
321 </table>
322 </td></tr>
323 </table>
324 </p><p>
325 <table
326 border=1 bgcolor=black>
327 <tr><td bgcolor=lightblue colspan=3>
328 <pre> </pre>
329 </td></tr>
330 <tr><td>
331 <table cellspacing=5 border=0
332 style="color:white;">
333 <tr><td>
334 <pre>
335 ugh branches
336 </pre>
337 </td></tr>
338 </table>
339 </td></tr>
340 </table>
341 </p><p>
342 shows the branches.
343 </p><p>
344 <table
345 border=1 bgcolor=black>
346 <tr><td bgcolor=lightblue colspan=3>
347 <pre> </pre>
348 </td></tr>
349 <tr><td>
350 <table cellspacing=5 border=0
351 style="color:white;">
352 <tr><td>
353 <pre>
354 ugh branch create BRANCH
355 </pre>
356 </td></tr>
357 </table>
358 </td></tr>
359 </table>
360 </p><p>
361 If you want to know what "rebase" means, this is how it would be spelt out:
362 </p><p>
363 <table
364 border=1 bgcolor=black>
365 <tr><td bgcolor=lightblue colspan=3>
366 <pre> </pre>
367 </td></tr>
368 <tr><td>
369 <table cellspacing=5 border=0
370 style="color:white;">
371 <tr><td>
372 <pre>
373 ugh branch move BRANCH
374 </pre>
375 </td></tr>
376 </table>
377 </td></tr>
378 </table>
379 </p><p>
380 Or something else, if you can come up with a more sensible name.
381 </p><p>
382 Now, how to handle "backward compatibility"?
383 </p><p>
384 No backwards compatibility. Not needed. Old farts like us can always use
385 </p><p>
386 <table
387 border=1 bgcolor=black>
388 <tr><td bgcolor=lightblue colspan=3>
389 <pre> </pre>
390 </td></tr>
391 <tr><td>
392 <table cellspacing=5 border=0
393 style="color:white;">
394 <tr><td>
395 <pre>
396 git make --me --sad
397 </pre>
398 </td></tr>
399 </table>
400 </td></tr>
401 </table>
402 </p><p>
403 or even
404 </p><p>
405 <table
406 border=1 bgcolor=black>
407 <tr><td bgcolor=lightblue colspan=3>
408 <pre> </pre>
409 </td></tr>
410 <tr><td>
411 <table cellspacing=5 border=0
412 style="color:white;">
413 <tr><td>
414 <pre>
415 git make ME^..sad
416 </pre>
417 </td></tr>
418 </table>
419 </td></tr>
420 </table>
421 </p><p>
422 By the way, even the usability of the string "ugh" is thought through: if you
423 use just one hand to type it very quickly, you end up with the correct finger
424 in the end.
425 </p><p>
426 <h4>Footnotes</h4>
427 </p><p>
428 <a name="foot-1" /><a href="#ref-1">1</a>: In the olden days, there were no
429 repositories to get from somewhere, so it is obvious why the initial user
430 interface design did not make that easy. Now, you might think that a "git clone"
431 is not too bad, but why all these differences between "clone", "fetch", "pull"?
432 Exactly, because the technical details -- the very same users could not care
433 less about -- are different.
434 </p>
435 <h6>Friday, 11th of June, Anno Domini MMX, at the hour of the Goat</h6>
436 <a name=1276255806>
437 <h2>New msysGit imminent</h2>
438
439 <p>
440 </p><p>
441 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.
442 </p>
443 <h6>Monday, 8th of February, Anno Domini MMX, at the hour of the Goat</h6>
444 <a name=1265634257>
445 <h2>Trying to get more time for msysGit</h2>
446
447 <p>
448 </p><p>
449 Nowadays, the msysGit project is driven forward mostly by Heiko Voigt,
450 Erik Faye-Lund, and of course the invaluable mingw.git work of Hannes
451 Sixt. The new-SVN, MinGW-SVN and MinGW-Python projects have stalled.
452 The latest msysGit release is <u>months</u> old.
453 </p><p>
454 It does not help that certain people on the Git mailing list write
455 looooong emails that nobody with my schedule can hope to read, rather
456 than being nice and spending some time to phrase what they have to
457 say in a <u>concise</u> manner.
458 </p><p>
459 Oh well. I will just concentrate on JGit and msysGit instead of
460 upstream Git, if I get some Git time.
461 </p>
462 <h6>Wednesday, 2nd of December, Anno Domini MMIX, at the hour of the Monkey</h6>
463 <a name=1259765885>
464 <h2>Avoiding to get angry</h2>
465
466 <p>
467 </p><p>
468 Despite many intelligent people realizing that the recent
469 change to special case http, https and ftp was a terrible decision, it
470 seems that there is enough resistance left on the Git mailing list to
471 keep the brain-dead current state.
472 </p><p>
473 The Git mailing list is definitely giving me more grief than joy these
474 days.
475 </p>
476 <h6>Sunday, 18th of October, Anno Domini MMIX, at the hour of the Goat</h6>
477 <a name=1255867912>
478 <h2>Git will never be user-friendly</h2>
479
480 <p>
481 </p><p>
482 Recently, encouraged by quite some private encouragement, I thought I could
483 take on the task of teaching the core Git developers how user-unfriendly
484 Git is, and that they should be more open to change (especially given that
485 1.7.0 was already announced to be a version that breaks recent expectations,
486 something I would have expected to merit a 2.0 -- but who am I anyway?).
487 </p><p>
488 It is quite ironic, in a very cruel sense, that those people who are such
489 big fans of educating the users instead of fixing their tools are unable
490 to be educated about something that should be obvious.
491 </p><p>
492 Yes, I am bitter.
493 </p>
494 <h6>Wednesday, 7th of October, Anno Domini MMIX, at the hour of the Rat</h6>
495 <a name=1254868748>
496 <h2>GitTogether in Berlin</h2>
497
498 <p>
499 </p><p>
500 We had a GitTogether in Berlin, called "Alles wird Git" (past tense: "Alles
501 wurde Git"). It was great fun, we never had even a single boring minute,
502 and our special guest -- Gitzilla -- turned out to be quite some entertainer,
503 especially when he starting reciting a few of my most outrageous emails &#x263a;
504 </p><p>
505 There were a lot of good discussions, among other things about submodules (our
506 neglected child), Git Cheetah, and foreign VCS helpers (in particular Sverre's
507 plan to provide some Mercurial backend).
508 </p><p>
509 One of the most important outcomes for me was, though, to realize just how
510 detached we in the Git project are from our user base. A few years back, we
511 could get away with saying "we have only developers as users, so they should
512 just sit down and scratch their own itch".
513 </p><p>
514 But today, we have a lot of users who never learnt to code (or who code in
515 some other language than C, or whose code we would not even want to review &#x263a;),
516 and we lose quite a few brownie points by keeping things complicated.
517 </p><p>
518 Now, in a lot of cases it cannot be helped. For example, we have confusing
519 names for things, inconsistent namings even (as with "remote" vs "tracked"
520 branches), and we have some odd design decisions (like calling some program
521 almost nobody uses "git cherry", which makes tab-completion of the rather
522 often-used "git cherry-pick" pretty awkward). The latter example also
523 illustrates that we have names for porcelains that are rather long, when
524 they should be rather short.
525 </p><p>
526 So, yes, we have a lot of things that do not work well, because we have
527 usability issues that need to be preserved for hysterical raisins.
528 </p><p>
529 This is unfortunate enough, but it seems that we even fsck up with usability
530 issues we <u>can</u> solve. Just think about "git checkout -b origin/master". A
531 typo? Yes, of course! But a rather obvious one.
532 </p><p>
533 Another case which was discussed on the mailing list recently: "git checkout
534 next" when clearly "git checkout origin/next" was meant.
535 </p><p>
536 The biggest problem, though, is that almost all people on the Git mailing list
537 who are respected by the maintainer are obviously too detached from the user
538 base to realize just how difficult Git <u>still</u> is. And refuse to do anything
539 about it, or even to allow others to do anything about it.
540 </p><p>
541 It almost seems as if the Git wizards do not want Git to become easier to
542 use, lest they lose their special status.
543 </p><p>
544 My biggest problem is that it seems that my input gets more and more ignored,
545 or perceived as some crazy ideas that will just go away (which is true, because
546 I am pretty happy about a day-job that keeps me more than just busy, so I do not
547 have time not fight windmills, let alone motiviation to do so).
548 </p><p>
549 Even when a real user comes along to chime in, he's just brushed off, by an
550 otherwise very polite maintainer.
551 </p><p>
552 I am not even sure if I want to continue sending my patches from my personal
553 tree upstream, because things get so frustrating, for little to show in return.
554 </p>
555 <h6>Sunday, 9th of August, Anno Domini MMIX, at the hour of the Rooster</h6>
556 <a name=1249835938>
557 <h2>The dilemma of being correct</h2>
558
559 <p>
560 </p><p>
561 So I am opinionated. No news there. The problem of being opinionated, though,
562 is that people do not take you seriously even if you are correct.
563 </p><p>
564 For example, I vividly remember having had concerns about the Git wrapper
565 being linked to <a href=http://curl.haxx.se/>cURL</a>, and I vividly remember
566 that our maintainer did not have such concerns and took Daniel's patch. I could
567 not find proof of my public comment quickly enough to add a link here, though.
568 </p><p>
569 Alas, there are serious problems with being correct:
570 </p><p>
571 <ol>
572 <li>If you're correct, you waste a lot of time trying to convince people (but
573 they ignore you nevertheless),
574 <li>Other people are regularly p*ssed off, especially when they find out
575 (or even worse, when it is pointed out to them) that they were wrong, and
576 <li>You can buy <u>nothing</u> for having been correct.
577 </ol>
578 </p><p>
579 It is a lose-lose situation.
580 </p><p>
581 In the current context, I am pretty certain that the rev cache and the pack
582 index are so similar in nature that we'll find quite a few issues that we had
583 with one repeated with the other.
584 </p><p>
585 As I <u>hate</u> losing time over a discussion others try to "win" -- which
586 invariably means that they refuse to be convinced of anything disagreeing with
587 their opinion &#x263a; -- I will just shut up, and probably have one or two odd
588 feelings when it turns out I was right.
589 </p>
590 <h6>Friday, 19th of June, Anno Domini MMIX, at the hour of the Monkey</h6>
591 <a name=1245419588>
592 <h2>The GraphGUI project</h2>
593
594 <p>
595 </p><p>
596 After a few unfortunate delays (and some fortunate ones, just not for us), the
597 GraphGUI project finally takes off. A quick first glance:
598 </p><p>
599 <center><img src=dscho.git?a=blob_plain;hb=c33212b23b2b3e45c14403efe82cabb1cd53f6e3;f=basic-gui.jpg basic-gui.jpg></center>
600 </p><p>
601 The delays were a bit unnerving, but the student is really bright and still
602 has the chance to pull the project off.
603 </p><p>
604 Next plans are to show text, too, to invent a rudimentary layout engine that
605 can be adjusted manually (this is in contrast to <i>gitk</i> or <i>log --graph</i>).
606 </p><p>
607 After that, integration into JGit (this probably triggered the eGit/JGit
608 split).
609 </p><p>
610 And then we'll go wild!
611 </p>
612 <h6>Friday, 15th of May, Anno Domini MMIX, at the hour of the Dog</h6>
613 <a name=1242408298>
614 <h2>Wasting way too much time on msysGit</h2>
615
616 <p>
617 </p><p>
618 I recently got into the bad habit of spending a large amount of my waking
619 hours working on msysGit, more than is really healthy for me.
620 </p><p>
621 For example, I spent the whole morning -- when I should have worked on a
622 very important day-job project -- on trying to fix issue 258, where
623 <i>git web--browse</i> does not work as expected because of quoting issues
624 with cmd.exe.
625 </p><p>
626 This is reducing my Git time budget to negative numbers, so much so that I
627 cannot even work on Git projects that I actually like, such as <i>jgit diff</i>
628 or <i>git rebase -i -p</i>, or at least projects I felt obliged to continue
629 to work on, such as <i>git notes</i>.
630 </p><p>
631 Now, some people who tried to teach me some time management strongly
632 criticized me for ignoring their lessons, and unfortunately, I have to agree.
633 </p><p>
634 The problem is that I would <u>hate</u> to see msysGit fall to the same state it
635 was after I stopped working on it last year. I started it, and I would like
636 it to grow, but too few people took care of the issue tracker, too few tried
637 to debug their problems themselves, too few submitted fixes.
638 </p><p>
639 I note, though, that there is a positive trend. But being the impatient person
640 I am ("2 seconds is my attention span") I tend to want the trend to be more
641 impressive.
642 </p><p>
643 Anyway, no work on msysGit for at least 4 days, that's what the doctor (me)
644 said...
645 </p>
646 <h6>Monday, 11th of May, Anno Domini MMIX, at the hour of the Rat</h6>
647 <a name=1241995759>
648 <h2>Working on jgit diff</h2>
649
650 <p>
651 </p><p>
652 Shawn did so many useful things that I use on a daily basis that I felt really
653 awful when I realized just how <u>long</u> I had promised to clean up that diff
654 implementation I wrote for JGit.
655 </p><p>
656 Alas, it appears that the thing turned out to be almost a complete rewrite, as
657 the original implementation walked the edit graph in a rather inefficient way.
658 </p><p>
659 A little background: Myers' algorithm to generate "an edit script" works on
660 the <i>edit graph</i>: imagine you have all lines of file <i>A</i> as columns and
661 all lines of file <i>B</i> as rows, then the <i>edit graph</i> is a connection of
662 the upper left corner to the lower right corner, containing only horizontal,
663 vertical or diagonal elements, where diagonal elements are only allowed when
664 the lines of both files agree at that point:
665 </p><p>
666 <pre>
667 H E L L O , W O R L D
668 ----
669 L \
670 ---
671 O \
672 ---
673 W \
674 --------
675 </pre>
676 </p><p>
677 The <i>shortest</i> edit path minimizes the number of non-diagonal elements.
678 </p><p>
679 Myers' idea is to develop forward and backward paths at the same time
680 (increasing the number of non-diagonal elements uniformly), storing
681 only the latest end points. Once the paths meet, divide and conquer.
682 </p><p>
683 In theory, it would be quicker to store <u>all</u> end points and then just
684 reconstruct the shortest paths, alas, this takes way too much memory.
685 </p><p>
686 My first implementation did not remember start or end of the non-diagonal
687 parts, and had to recurse way more often than really necessary (in the end,
688 we will order the non-diagonal parts into horizontal and vertical parts
689 anyway, so start and end are sufficient).
690 </p><p>
691 The current progress can be seen <a href=http://repo.or.cz/w/egit/dscho.git/>
692 here</a>.
693 </p>
694 </div>
695 </body>
696 </html>
Dscho's miscellaneous git branches