source-1289325547.txt

   1 Fun brainstorm session about "Users' Git Helper", a potential new porcelain
   2
   3 In a not so serious Skype conversation, the issue of Git's usability came
   4 up. Once again. It is a sad thing that still, the user interface design of
   5 Git has nothing in common with the straight-forward, beautiful and simple
   6 design of the data structures beneath.
   7
   8 It is still quite common for me to suggest using Subversion to other people
   9 because it is easier to use.
  10
  11 So the idea was to have a new "porcelain" for Git, which would try much,
  12 much harder to be intuitive than all the other porcelains which try to fix
  13 the user interface warts of the Git command line interface.
  14
  15 In other words, the idea is that there is no way you can fix the command-line
  16 interface, for a number of reasons, not the least of which is the inertia of
  17 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:
  18 <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.
  19
  20 Guiding principle would be the 80 percent solution, or analogously:
  21
  22 <ul>
  23 <li> Optimize for the common case.
  24 <li> Make the simple easy and the difficult possible.
  25 <li> Before the green button, the Xerox machine was unusable.
  26 </ul>
  27
  28 So many different ways to describe the same thing :-)
  29
  30 But enough of the philosophical talk. Let's look at some possible interface design. First things first, the name. Users' Git Helper:
  31
  32 <bash>
  33 ugh
  34 </bash>
  35
  36 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:
  37
  38 <bash>
  39 ugh get URL
  40 </bash>
  41
  42 The next thing is probably that you want to look at what you got.
  43
  44 <bash>
  45 ugh show [ANYTHING, INCLUDING COMMIT NAMES]
  46 </bash>
  47
  48 It would default at showing the current commit, with the branch name and then
  49 the abbreviated commit name in parentheses.
  50
  51 In general, no command would show the usage when called without options. That
  52 is what
  53
  54 <bash>
  55 ugh help COMMAND
  56 </bash>
  57
  58 is for. And this command would not call 'man' to do the job. It would do the
  59 job.
  60
  61 <bash>
  62 ugh commit
  63 </bash>
  64
  65 would have no options, as it tries to discover what is there, and lets the user
  66 choose between options, most sensible ones first.
  67
  68 To share your work with others,
  69
  70 <bash>
  71 ugh publish [REMOTE]
  72 </bash>
  73
  74 would do that. The default remote would be the one from which you branched off.
  75
  76 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>:
  77
  78 <bash>
  79 ugh undo
  80 </bash>
  81
  82 The 'undo' command must be intelligent about what makes sense and what not.
  83 For example, once published, the commit should not be undoable, except on
  84 another branch. And undoing a "publish" should not be possible, except if
  85 the respective remote is marked as "personal", and the user should be told
  86 how to set this conveniently.
  87
  88 Inside a repository, "ugh get" would try to pull the tracked branch if it
  89 fast-forwards (but it would not say the word "fast-forward"; I had to explain
  90 the meaning of that term one hundred billion times; one hundred billion times
  91 too many, if you ask me), but fetch in any case and error out with the message
  92 that there are local commits in addition to remote ones, so a merge is
  93 necessary:
  94
  95 <bash>
  96 ugh merge [REMOTE [BRANCH]]
  97 </bash>
  98
  99 Since people are familiar with other commands, "ugh <command> --help" would be
 100 an alias to "ugh help <command>". But it would not be advertised in the
 101 documentation, because documentation is where you learn how the program is
 102 intended to be used.
 103
 104 No rebase.
 105
 106 What is a "rebase"? What would you have answered in 2004? Me, too, I would have
 107 said "dunno, tell me!".
 108
 109 So it is all about branches.
 110
 111 <bash>
 112 ugh branch
 113 </bash>
 114
 115 <bash>
 116 ugh branches
 117 </bash>
 118
 119 shows the branches.
 120
 121 <bash>
 122 ugh branch create BRANCH
 123 </bash>
 124
 125 If you want to know what "rebase" means, this is how it would be spelt out:
 126
 127 <bash>
 128 ugh branch move BRANCH
 129 </bash>
 130
 131 Or something else, if you can come up with a more sensible name.
 132
 133 Now, how to handle "backward compatibility"?
 134
 135 No backwards compatibility. Not needed. Old farts like us can always use
 136
 137 <bash>
 138 git make --me --sad
 139 </bash>
 140
 141 or even
 142
 143 <bash>
 144 git make ME^..sad
 145 </bash>
 146
 147 By the way, even the usability of the string "ugh" is thought through: if you
 148 use just one hand to type it very quickly, you end up with the correct finger
 149 in the end.
 150
 151 <h4>Footnotes</h4>
 152
 153 <a name="foot-1" /><a href="#ref-1">1</a>: In the olden days, there were no
 154 repositories to get from somewhere, so it is obvious why the initial user
 155 interface design did not make that easy. Now, you might think that a "git clone"
 156 is not too bad, but why all these differences between "clone", "fetch", "pull"?
 157 Exactly, because the technical details -- the very same users could not care
 158 less about -- are different.