| blob | 771f70daf7241efa84684d7f30950d88bfd7fa0a |
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[Fun brainstorm session about "Users' Git Helper", a potential new porcelain
16 </p><p>
17 In a not so serious Skype conversation, the issue of Git's usability came
18 up. Once again. It is a sad thing that still, the user interface design of
19 Git has nothing in common with the straight-forward, beautiful and simple
20 design of the data structures beneath.
21 </p><p>
22 It is still quite common for me to suggest using Subversion to other people
23 because it is easier to use.
24 </p><p>
25 So the idea was to have a new "porcelain" for Git, which would try much,
26 much harder to be intuitive than all the other porcelains which try to fix
27 the user interface warts of the Git command line interface.
28 </p><p>
29 In other words, the idea is that there is no way you can fix the command-line
30 interface, for a number of reasons, not the least of which is the inertia of
31 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:
32 <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.
33 </p><p>
34 Guiding principle would be the 80 percent solution, or analogously:
35 </p><p>
36 <ul>
37 <li> Optimize for the common case.
38 <li> Make the simple easy and the difficult possible.
39 <li> Before the green button, the Xerox machine was unusable.
40 </ul>
41 </p><p>
42 So many different ways to describe the same thing ☺
43 </p><p>
44 But enough of the philosophical talk. Let's look at some possible interface design. First things first, the name. Users' Git Helper:
45 </p><p>
46 <table
49 <pre> </pre>
50 </td></tr>
51 <tr><td>
54 <tr><td>
55 <pre>
56 ugh
57 </pre>
58 </td></tr>
59 </table>
60 </td></tr>
61 </table>
62 </p><p>
63 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:
64 </p><p>
65 <table
68 <pre> </pre>
69 </td></tr>
70 <tr><td>
73 <tr><td>
74 <pre>
75 ugh get URL
76 </pre>
77 </td></tr>
78 </table>
79 </td></tr>
80 </table>
81 </p><p>
82 The next thing is probably that you want to look at what you got.
83 </p><p>
84 <table
87 <pre> </pre>
88 </td></tr>
89 <tr><td>
92 <tr><td>
93 <pre>
94 ugh show [ANYTHING, INCLUDING COMMIT NAMES]
95 </pre>
96 </td></tr>
97 </table>
98 </td></tr>
99 </table>
100 </p><p>
101 It would default at showing the current commit, with the branch name and then
102 the abbreviated commit name in parentheses.
103 </p><p>
104 In general, no command would show the usage when called without options. That
105 is what
106 </p><p>
107 <table
110 <pre> </pre>
111 </td></tr>
112 <tr><td>
115 <tr><td>
116 <pre>
117 ugh help COMMAND
118 </pre>
119 </td></tr>
120 </table>
121 </td></tr>
122 </table>
123 </p><p>
124 is for. And this command would not call 'man' to do the job. It would do the
125 job.
126 </p><p>
127 <table
130 <pre> </pre>
131 </td></tr>
132 <tr><td>
135 <tr><td>
136 <pre>
137 ugh commit
138 </pre>
139 </td></tr>
140 </table>
141 </td></tr>
142 </table>
143 </p><p>
144 would have no options, as it tries to discover what is there, and lets the user
145 choose between options, most sensible ones first.
146 </p><p>
147 To share your work with others,
148 </p><p>
149 <table
152 <pre> </pre>
153 </td></tr>
154 <tr><td>
157 <tr><td>
158 <pre>
159 ugh publish [REMOTE]
160 </pre>
161 </td></tr>
162 </table>
163 </td></tr>
164 </table>
165 </p><p>
166 would do that. The default remote would be the one from which you branched off.
167 </p><p>
168 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>:
169 </p><p>
170 <table
173 <pre> </pre>
174 </td></tr>
175 <tr><td>
178 <tr><td>
179 <pre>
180 ugh undo
181 </pre>
182 </td></tr>
183 </table>
184 </td></tr>
185 </table>
186 </p><p>
187 The 'undo' command must be intelligent about what makes sense and what not.
188 For example, once published, the commit should not be undoable, except on
189 another branch. And undoing a "publish" should not be possible, except if
190 the respective remote is marked as "personal", and the user should be told
191 how to set this conveniently.
192 </p><p>
193 Inside a repository, "ugh get" would try to pull the tracked branch if it
194 fast-forwards (but it would not say the word "fast-forward"; I had to explain
195 the meaning of that term one hundred billion times; one hundred billion times
196 too many, if you ask me), but fetch in any case and error out with the message
197 that there are local commits in addition to remote ones, so a merge is
198 necessary:
199 </p><p>
200 <table
203 <pre> </pre>
204 </td></tr>
205 <tr><td>
208 <tr><td>
209 <pre>
210 ugh merge [REMOTE [BRANCH]]
211 </pre>
212 </td></tr>
213 </table>
214 </td></tr>
215 </table>
216 </p><p>
217 Since people are familiar with other commands, "ugh COMMAND --help" would be
218 an alias to "ugh help COMMAND". But it would not be advertised in the
219 documentation, because documentation is where you learn how the program is
220 intended to be used.
221 </p><p>
222 No rebase.
223 </p><p>
225 said "dunno, tell me!".
226 </p><p>
227 So it is all about branches.
228 </p><p>
229 <table
232 <pre> </pre>
233 </td></tr>
234 <tr><td>
237 <tr><td>
238 <pre>
239 ugh branches
240 </pre>
241 </td></tr>
242 </table>
243 </td></tr>
244 </table>
245 </p><p>
246 shows the branches. Make a new branch from the current state:
247 </p><p>
248 <table
251 <pre> </pre>
252 </td></tr>
253 <tr><td>
256 <tr><td>
257 <pre>
258 ugh branch create BRANCH
259 </pre>
260 </td></tr>
261 </table>
262 </td></tr>
263 </table>
264 </p><p>
265 Make a new branch from another state:
266 </p><p>
267 <table
270 <pre> </pre>
271 </td></tr>
272 <tr><td>
275 <tr><td>
276 <pre>
277 ugh branch create BRANCH from OTHER-BRANCH
278 </pre>
279 </td></tr>
280 </table>
281 </td></tr>
282 </table>
283 </p><p>
284 where the other branch can be a local or a remote one. If there are more than
285 one possibility, the command asks you.
286 </p><p>
287 If you want to know what "rebase" means, this is how it would be spelt out:
288 </p><p>
289 <table
292 <pre> </pre>
293 </td></tr>
294 <tr><td>
297 <tr><td>
298 <pre>
299 ugh branch move onto BRANCH
300 </pre>
301 </td></tr>
302 </table>
303 </td></tr>
304 </table>
305 </p><p>
306 Or something else, if you can come up with a more sensible name.
307 </p><p>
308 Now, how to handle "backward compatibility"?
309 </p><p>
310 No backwards compatibility. Not needed. Old farts like me can always use
311 </p><p>
312 <table
315 <pre> </pre>
316 </td></tr>
317 <tr><td>
320 <tr><td>
321 <pre>
322 git make --me --sad
323 </pre>
324 </td></tr>
325 </table>
326 </td></tr>
327 </table>
328 </p><p>
329 or even
330 </p><p>
331 <table
334 <pre> </pre>
335 </td></tr>
336 <tr><td>
339 <tr><td>
340 <pre>
341 git make ME^..sad
342 </pre>
343 </td></tr>
344 </table>
345 </td></tr>
346 </table>
347 </p><p>
348 By the way, even the usability of the string "ugh" is thought through: if you
349 use just one hand to type it very quickly, you end up with the correct finger
350 in the end.
351 </p><p>
353 </p><p>
355 repositories to get from somewhere, so it is obvious why the initial user
356 interface design did not make that easy. Now, you might think that a "git clone"
358 This is exactly the problem, because the technical details are different. The
359 very same details the users could not care less about. The very same details the
361 </item>
362 <item>
367 <description><![CDATA[New msysGit imminent
368 </p><p>
369 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>
370 </item>
371 <item>
376 <description><![CDATA[Trying to get more time for msysGit
377 </p><p>
378 Nowadays, the msysGit project is driven forward mostly by Heiko Voigt,
379 Erik Faye-Lund, and of course the invaluable mingw.git work of Hannes
380 Sixt. The new-SVN, MinGW-SVN and MinGW-Python projects have stalled.
382 </p><p>
383 It does not help that certain people on the Git mailing list write
384 looooong emails that nobody with my schedule can hope to read, rather
385 than being nice and spending some time to phrase what they have to
387 </p><p>
388 Oh well. I will just concentrate on JGit and msysGit instead of
389 upstream Git, if I get some Git time.]]></description>
390 </item>
391 <item>
396 <description><![CDATA[Avoiding to get angry
397 </p><p>
398 Despite many intelligent people realizing that the recent
399 change to special case http, https and ftp was a terrible decision, it
400 seems that there is enough resistance left on the Git mailing list to
401 keep the brain-dead current state.
402 </p><p>
403 The Git mailing list is definitely giving me more grief than joy these
404 days.]]></description>
405 </item>
406 <item>
411 <description><![CDATA[Git will never be user-friendly
412 </p><p>
413 Recently, encouraged by quite some private encouragement, I thought I could
414 take on the task of teaching the core Git developers how user-unfriendly
415 Git is, and that they should be more open to change (especially given that
416 1.7.0 was already announced to be a version that breaks recent expectations,
417 something I would have expected to merit a 2.0 -- but who am I anyway?).
418 </p><p>
419 It is quite ironic, in a very cruel sense, that those people who are such
420 big fans of educating the users instead of fixing their tools are unable
421 to be educated about something that should be obvious.
422 </p><p>
423 Yes, I am bitter.]]></description>
424 </item>
425 <item>
430 <description><![CDATA[GitTogether in Berlin
431 </p><p>
433 wurde Git"). It was great fun, we never had even a single boring minute,
434 and our special guest -- Gitzilla -- turned out to be quite some entertainer,
435 especially when he starting reciting a few of my most outrageous emails ☺
436 </p><p>
437 There were a lot of good discussions, among other things about submodules (our
438 neglected child), Git Cheetah, and foreign VCS helpers (in particular Sverre's
439 plan to provide some Mercurial backend).
440 </p><p>
441 One of the most important outcomes for me was, though, to realize just how
442 detached we in the Git project are from our user base. A few years back, we
443 could get away with saying "we have only developers as users, so they should
444 just sit down and scratch their own itch".
445 </p><p>
446 But today, we have a lot of users who never learnt to code (or who code in
447 some other language than C, or whose code we would not even want to review ☺),
448 and we lose quite a few brownie points by keeping things complicated.
449 </p><p>
450 Now, in a lot of cases it cannot be helped. For example, we have confusing
452 branches), and we have some odd design decisions (like calling some program
453 almost nobody uses "git cherry", which makes tab-completion of the rather
454 often-used "git cherry-pick" pretty awkward). The latter example also
455 illustrates that we have names for porcelains that are rather long, when
456 they should be rather short.
457 </p><p>
458 So, yes, we have a lot of things that do not work well, because we have
459 usability issues that need to be preserved for hysterical raisins.
460 </p><p>
461 This is unfortunate enough, but it seems that we even fsck up with usability
463 typo? Yes, of course! But a rather obvious one.
464 </p><p>
465 Another case which was discussed on the mailing list recently: "git checkout
467 </p><p>
468 The biggest problem, though, is that almost all people on the Git mailing list
469 who are respected by the maintainer are obviously too detached from the user
471 about it, or even to allow others to do anything about it.
472 </p><p>
473 It almost seems as if the Git wizards do not want Git to become easier to
474 use, lest they lose their special status.
475 </p><p>
476 My biggest problem is that it seems that my input gets more and more ignored,
477 or perceived as some crazy ideas that will just go away (which is true, because
478 I am pretty happy about a day-job that keeps me more than just busy, so I do not
479 have time not fight windmills, let alone motiviation to do so).
480 </p><p>
481 Even when a real user comes along to chime in, he's just brushed off, by an
482 otherwise very polite maintainer.
483 </p><p>
484 I am not even sure if I want to continue sending my patches from my personal
485 tree upstream, because things get so frustrating, for little to show in return.]]></description>
486 </item>
487 <item>
492 <description><![CDATA[The dilemma of being correct
493 </p><p>
494 So I am opinionated. No news there. The problem of being opinionated, though,
495 is that people do not take you seriously even if you are correct.
496 </p><p>
497 For example, I vividly remember having had concerns about the Git wrapper
499 that our maintainer did not have such concerns and took Daniel's patch. I could
500 not find proof of my public comment quickly enough to add a link here, though.
501 </p><p>
502 Alas, there are serious problems with being correct:
503 </p><p>
504 <ol>
505 <li>If you're correct, you waste a lot of time trying to convince people (but
506 they ignore you nevertheless),
507 <li>Other people are regularly p*ssed off, especially when they find out
508 (or even worse, when it is pointed out to them) that they were wrong, and
510 </ol>
511 </p><p>
512 It is a lose-lose situation.
513 </p><p>
514 In the current context, I am pretty certain that the rev cache and the pack
515 index are so similar in nature that we'll find quite a few issues that we had
516 with one repeated with the other.
517 </p><p>
519 invariably means that they refuse to be convinced of anything disagreeing with
520 their opinion ☺ -- I will just shut up, and probably have one or two odd
521 feelings when it turns out I was right.]]></description>
522 </item>
523 <item>
528 <description><![CDATA[The GraphGUI project
529 </p><p>
530 After a few unfortunate delays (and some fortunate ones, just not for us), the
531 GraphGUI project finally takes off. A quick first glance:
532 </p><p>
533 <center><img src=dscho.git?a=blob_plain;hb=c33212b23b2b3e45c14403efe82cabb1cd53f6e3;f=basic-gui.jpg basic-gui.jpg></center>
534 </p><p>
535 The delays were a bit unnerving, but the student is really bright and still
536 has the chance to pull the project off.
537 </p><p>
538 Next plans are to show text, too, to invent a rudimentary layout engine that
540 </p><p>
541 After that, integration into JGit (this probably triggered the eGit/JGit
542 split).
543 </p><p>
544 And then we'll go wild!]]></description>
545 </item>
546 <item>
551 <description><![CDATA[Wasting way too much time on msysGit
552 </p><p>
553 I recently got into the bad habit of spending a large amount of my waking
554 hours working on msysGit, more than is really healthy for me.
555 </p><p>
556 For example, I spent the whole morning -- when I should have worked on a
557 very important day-job project -- on trying to fix issue 258, where
559 with cmd.exe.
560 </p><p>
561 This is reducing my Git time budget to negative numbers, so much so that I
565 </p><p>
566 Now, some people who tried to teach me some time management strongly
567 criticized me for ignoring their lessons, and unfortunately, I have to agree.
568 </p><p>
570 was after I stopped working on it last year. I started it, and I would like
571 it to grow, but too few people took care of the issue tracker, too few tried
572 to debug their problems themselves, too few submitted fixes.
573 </p><p>
574 I note, though, that there is a positive trend. But being the impatient person
575 I am ("2 seconds is my attention span") I tend to want the trend to be more
576 impressive.
577 </p><p>
578 Anyway, no work on msysGit for at least 4 days, that's what the doctor (me)
579 said...]]></description>
580 </item>
581 <item>
586 <description><![CDATA[Working on jgit diff
587 </p><p>
588 Shawn did so many useful things that I use on a daily basis that I felt really
590 implementation I wrote for JGit.
591 </p><p>
592 Alas, it appears that the thing turned out to be almost a complete rewrite, as
593 the original implementation walked the edit graph in a rather inefficient way.
594 </p><p>
595 A little background: Myers' algorithm to generate "an edit script" works on
598 the upper left corner to the lower right corner, containing only horizontal,
599 vertical or diagonal elements, where diagonal elements are only allowed when
600 the lines of both files agree at that point:
601 </p><p>
602 <pre>
603 H E L L O , W O R L D
604 ----
605 L \
606 ---
607 O \
608 ---
609 W \
610 --------
611 </pre>
612 </p><p>
614 </p><p>
615 Myers' idea is to develop forward and backward paths at the same time
616 (increasing the number of non-diagonal elements uniformly), storing
617 only the latest end points. Once the paths meet, divide and conquer.
618 </p><p>
620 reconstruct the shortest paths, alas, this takes way too much memory.
621 </p><p>
622 My first implementation did not remember start or end of the non-diagonal
623 parts, and had to recurse way more often than really necessary (in the end,
624 we will order the non-diagonal parts into horizontal and vertical parts
625 anyway, so start and end are sufficient).
626 </p><p>
629 </item>
630 </channel>
631 </rss>