From 5ff0352c13db5cd44e4c8a07f604f949e19bcd17 Mon Sep 17 00:00:00 2001 From: Johannes Schindelin Date: Wed, 7 Oct 2009 00:39:09 +0200 Subject: [PATCH] Housekeeping on Wednesday, 7th of October, Anno Domini MMIX, at the hour of the Rat Signed-off-by: Johannes Schindelin --- blog.rss | 114 ++++++++++++++++++++++++++++---------------------- source-1234409395.txt | 31 -------------- 2 files changed, 63 insertions(+), 82 deletions(-) delete mode 100644 source-1234409395.txt diff --git a/blog.rss b/blog.rss index 63f608db65..2a343ff5e1 100644 --- a/blog.rss +++ b/blog.rss @@ -5,9 +5,71 @@ http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html A few stories told by Dscho -Sun, 09 Aug 2009 18:38:58 +0200 +Wed, 07 Oct 2009 00:39:08 +0200 en-us +GitTogether in Berlin +http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1254868748 +http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1254868748 +Wed, 07 Oct 2009 00:39:08 +0200 +

+We had a GitTogether in Berlin, called "Alles wird Git" (past tense: "Alles +wurde Git"). It was great fun, we never had even a single boring minute, +and our special guest -- Gitzilla -- turned out to be quite some entertainer, +especially when he starting reciting a few of my most outrageous emails ☺ +

+There were a lot of good discussions, among other things about submodules (our +neglected child), Git Cheetah, and foreign VCS helpers (in particular Sverre's +plan to provide some Mercurial backend). +

+One of the most important outcomes for me was, though, to realize just how +detached we in the Git project are from our user base. A few years back, we +could get away with saying "we have only developers as users, so they should +just sit down and scratch their own itch". +

+But today, we have a lot of users who never learnt to code (or who code in +some other language than C, or whose code we would not even want to review ☺), +and we lose quite a few brownie points by keeping things complicated. +

+Now, in a lot of cases it cannot be helped. For example, we have confusing +names for things, inconsistent namings even (as with "remote" vs "tracked" +branches), and we have some odd design decisions (like calling some program +almost nobody uses "git cherry", which makes tab-completion of the rather +often-used "git cherry-pick" pretty awkward). The latter example also +illustrates that we have names for porcelains that are rather long, when +they should be rather short. +

+So, yes, we have a lot of things that do not work well, because we have +usability issues that need to be preserved for hysterical raisins. +

+This is unfortunate enough, but it seems that we even fsck up with usability +issues we can solve. Just think about "git checkout -b origin/master". A +typo? Yes, of course! But a rather obvious one. +

+Another case which was discussed on the mailing list recently: "git checkout +next" when clearly "git checkout origin/next" was meant. +

+The biggest problem, though, is that almost all people on the Git mailing list +who are respected by the maintainer are obviously too detached from the user +base to realize just how difficult Git still is. And refuse to do anything +about it, or even to allow others to do anything about it. +

+It almost seems as if the Git wizards do not want Git to become easier to +use, lest they lose their special status. +

+My biggest problem is that it seems that my input gets more and more ignored, +or perceived as some crazy ideas that will just go away (which is true, because +I am pretty happy about a day-job that keeps me more than just busy, so I do not +have time not fight windmills, let alone motiviation to do so). +

+Even when a real user comes along to chime in, he's just brushed off, by an +otherwise very polite maintainer. +

+I am not even sure if I want to continue sending my patches from my personal +tree upstream, because things get so frustrating, for little to show in return.]]> + + The dilemma of being correct http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1249835938 http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1249835938 @@ -276,55 +338,5 @@ And they almost succeeded. So I guess it is time to reassess my priorities, and maybe stop reviewing Git patches altogether.]]> - -Interactive rebase just learnt a new command: topic -http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1234409395 -http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1234409395 -Thu, 12 Feb 2009 04:29:55 +0100 -rebase just learnt a new command: topic -

-Today I am pretty pleased with myself. Two projects at my day job got a real -boost, and I implemented a shortcut that avoids the ugly 'bookmark' statement -in rebase scripts most of the time. -

-A typical rebase script, generated by git rebase -i -p $COMMIT will look -something like this: -

- - - -
-
-
- - -
- 
-pick 1234567 My first commit
-topic begin super-cool-feature
-pick 2345678 The super cool feature
-pick 3456789 Documentation for the super cool feature
-topic end super-cool-feature
-
-
-
-

-The result will be a merge commit at the HEAD whose first parent is -"My first commit", whose second parent is "Documentation for the super -cool feature" and whose commit message is "Merge branch 'super-cool-feature'". -

-Side note: internally, topic begin $NAME [at $COMMIT] will be handled as if -you wrote bookmark merge-parent-of-$NAME; goto $COMMIT, and -topic end $NAME [$MESSAGE] will be handled as if you wrote -bookmark $NAME; goto merge-parent-of-$NAME; merge parents $NAME [original $MARK Merge branch '$NAME']. -

-Of course, being more concise, the 'topic' statement is not only nicer to the -eye, but also less error-prone. -

-And hopefully many people will agree with me that this rebase script is pretty -intuitive.]]> - diff --git a/source-1234409395.txt b/source-1234409395.txt deleted file mode 100644 index e5463ad1bb..0000000000 --- a/source-1234409395.txt +++ /dev/null @@ -1,31 +0,0 @@ -Interactive ''rebase'' just learnt a new command: ''topic'' - -Today I am pretty pleased with myself. Two projects at my day job got a real -boost, and I implemented a shortcut that avoids the ugly 'bookmark' statement -in rebase scripts most of the time. - -A typical rebase script, generated by ''git rebase -i -p $COMMIT'' will look -something like this: - - -pick 1234567 My first commit -topic begin super-cool-feature -pick 2345678 The super cool feature -pick 3456789 Documentation for the super cool feature -topic end super-cool-feature - - -The result will be a merge commit at the HEAD whose first parent is -"My first commit", whose second parent is "Documentation for the super -cool feature" and whose commit message is "Merge branch 'super-cool-feature'". - -Side note: internally, ''topic begin $NAME [at $COMMIT]'' will be handled as if -you wrote ''bookmark merge-parent-of-$NAME; goto $COMMIT'', and -''topic end $NAME [$MESSAGE]'' will be handled as if you wrote -''bookmark $NAME; goto merge-parent-of-$NAME; merge parents $NAME [original $MARK Merge branch '$NAME']''. - -Of course, being more concise, the 'topic' statement is not only nicer to the -eye, but also less error-prone. - -And hopefully many people will agree with me that this rebase script is pretty -intuitive. -- 2.11.4.GIT