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 branches
 113 </bash>
 114
 115 shows the branches. Make a new branch from the current state:
 116
 117 <bash>
 118 ugh branch create BRANCH
 119 </bash>
 120
 121 Make a new branch from another state:
 122
 123 <bash>
 124 ugh branch create BRANCH from OTHER-BRANCH
 125 </bash>
 126
 127 where the other branch can be a local or a remote one. If there are more than
 128 one possibility, the command asks you.
 129
 130 If you want to know what "rebase" means, this is how it would be spelt out:
 131
 132 <bash>
 133 ugh branch move onto BRANCH
 134 </bash>
 135
 136 Or something else, if you can come up with a more sensible name.
 137
 138 Now, how to handle "backward compatibility"?
 139
 140 No backwards compatibility. Not needed. Old farts like me can always use
 141
 142 <bash>
 143 git make --me --sad
 144 </bash>
 145
 146 or even
 147
 148 <bash>
 149 git make ME^..sad
 150 </bash>
 151
 152 By the way, even the usability of the string "ugh" is thought through: if you
 153 use just one hand to type it very quickly, you end up with the correct finger
 154 in the end.
 155
 156 <h4>Footnotes</h4>
 157
 158 <a name="foot-1" /><a href="#ref-1">1</a>: In the olden days, there were no
 159 repositories to get from somewhere, so it is obvious why the initial user
 160 interface design did not make that easy. Now, you might think that a "git clone"
 161 is not too bad, but why all these differences between "clone", "fetch", "pull"?
 162 This is exactly the problem, because the technical details are different. The
 163 very same details the users could not care less about. The very same details the
 164 users should not _need_ to care about.