From 7a1b1b9a712046062c668cd4e41d06b0c7a08e54 Mon Sep 17 00:00:00 2001 From: Johannes Schindelin Date: Tue, 9 Nov 2010 18:59:07 +0100 Subject: [PATCH] Housekeeping on Tuesday, 9th of November, Anno Domini MMX, at the hour of the Rooster Signed-off-by: Johannes Schindelin --- blog.rss | 363 +++++++++++++++++++++++++++++++++++++++++++++++--- source-1239975597.txt | 7 - 2 files changed, 348 insertions(+), 22 deletions(-) delete mode 100644 source-1239975597.txt diff --git a/blog.rss b/blog.rss index a029e390dc..53defbd2cc 100644 --- a/blog.rss +++ b/blog.rss @@ -1,13 +1,359 @@ -Dscho's git log +Dscho's Git log http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html A few stories told by Dscho -Fri, 11 Jun 2010 13:30:59 +0200 +Tue, 09 Nov 2010 18:59:07 +0100 en-us +Fun brainstorm session about "Users' Git Helper", a potential new porcelain +http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1289325547 +http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1289325547 +Tue, 09 Nov 2010 18:59:07 +0100 +

+In a not so serious Skype conversation, the issue of Git's usability came +up. Once again. It is a sad thing that still, the user interface design of +Git has nothing in common with the straight-forward, beautiful and simple +design of the data structures beneath. +

+It is still quite common for me to suggest using Subversion to other people +because it is easier to use. +

+So the idea was to have a new "porcelain" for Git, which would try much, +much harder to be intuitive than all the other porcelains which try to fix +the user interface warts of the Git command line interface. +

+In other words, the idea is that there is no way you can fix the command-line +interface, for a number of reasons, not the least of which is the inertia of +a precious few power-users, which according to Apple's Human Interface Guidelines is not a good thing: +"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.". Just as an example, what does splitting a mailbox into individual mails have to do with Version Control? Exactly. +

+Guiding principle would be the 80 percent solution, or analogously: +

+

    +
  • Optimize for the common case. +
  • Make the simple easy and the difficult possible. +
  • Before the green button, the Xerox machine was unusable. +
+

+So many different ways to describe the same thing ☺ +

+But enough of the philosophical talk. Let's look at some possible interface design. First things first, the name. Users' Git Helper: +

+ + + +
+
+
+ + +
+ 
+ugh
+
+
+
+

+The first thing you usually want to do1: get the project from somewhere: +

+ + + +
+
+
+ + +
+ 
+ugh get URL
+
+
+
+

+The next thing is probably that you want to look at what you got. +

+ + + +
+
+
+ + +
+ 
+ugh show [ANYTHING, INCLUDING COMMIT NAMES]
+
+
+
+

+It would default at showing the current commit, with the branch name and then +the abbreviated commit name in parentheses. +

+In general, no command would show the usage when called without options. That +is what +

+ + + +
+
+
+ + +
+ 
+ugh help COMMAND
+
+
+
+

+is for. And this command would not call 'man' to do the job. It would do the +job. +

+ + + +
+
+
+ + +
+ 
+ugh commit
+
+
+
+

+would have no options, as it tries to discover what is there, and lets the user +choose between options, most sensible ones first. +

+To share your work with others, +

+ + + +
+
+
+ + +
+ 
+ugh publish [REMOTE]
+
+
+
+

+would do that. The default remote would be the one from which you branched off. +

+Oh, and of course, there must be an undo: +

+ + + +
+
+
+ + +
+ 
+ugh undo
+
+
+
+

+The 'undo' command must be intelligent about what makes sense and what not. +For example, once published, the commit should not be undoable, except on +another branch. And undoing a "publish" should not be possible, except if +the respective remote is marked as "personal", and the user should be told +how to set this conveniently. +

+Inside a repository, "ugh get" would try to pull the tracked branch if it +fast-forwards (but it would not say the word "fast-forward"; I had to explain +the meaning of that term one hundred billion times; one hundred billion times +too many, if you ask me), but fetch in any case and error out with the message +that there are local commits in addition to remote ones, so a merge is +necessary: +

+ + + +
+
+
+ + +
+ 
+ugh merge [REMOTE [BRANCH]]
+
+
+
+

+Since people are familiar with other commands, "ugh --help" would be +an alias to "ugh help ". But it would not be advertised in the +documentation, because documentation is where you learn how the program is +intended to be used. +

+No rebase. +

+What is a "rebase"? What would you have answered in 2004? Me, too, I would have +said "dunno, tell me!". +

+So it is all about branches. +

+ + + +
+
+
+ + +
+ 
+ugh branch
+
+
+
+

+ + + +
+
+
+ + +
+ 
+ugh branches
+
+
+
+

+shows the branches. +

+ + + +
+
+
+ + +
+ 
+ugh branch create BRANCH
+
+
+
+

+If you want to know what "rebase" means, this is how it would be spelt out: +

+ + + +
+
+
+ + +
+ 
+ugh branch move BRANCH
+
+
+
+

+Or something else, if you can come up with a more sensible name. +

+Now, how to handle "backward compatibility"? +

+No backwards compatibility. Not needed. Old farts like us can always use +

+ + + +
+
+
+ + +
+ 
+git make --me --sad
+
+
+
+

+or even +

+ + + +
+
+
+ + +
+ 
+git make ME^..sad
+
+
+
+

+By the way, even the usability of the string "ugh" is thought through: if you +use just one hand to type it very quickly, you end up with the correct finger +in the end. +

+

Footnotes

+

+1: In the olden days, there were no +repositories to get from somewhere, so it is obvious why the initial user +interface design did not make that easy. Now, you might think that a "git clone" +is not too bad, but why all these differences between "clone", "fetch", "pull"? +Exactly, because the technical details -- the very same users could not care +less about -- are different.]]> + + New msysGit imminent http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1276255806 http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1276255806 @@ -275,18 +621,5 @@ anyway, so start and end are sufficient). The current progress can be seen here.]]> - -No time for Git -http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1239975597 -http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1239975597 -Fri, 17 Apr 2009 15:39:57 +0200 -

-It is a shame, but most of my Git time budget is taken by msysGit these -days. -

-But at least msysGit is moving again; I'll probably write a Herald about -it.]]> - diff --git a/source-1239975597.txt b/source-1239975597.txt deleted file mode 100644 index 50ff3bb6b1..0000000000 --- a/source-1239975597.txt +++ /dev/null @@ -1,7 +0,0 @@ -No time for Git - -It is a shame, but most of my Git time budget is taken by msysGit these -days. - -But at least msysGit is moving again; I'll probably write a Herald about -it. -- 2.11.4.GIT