Dscho's Git log

Table of contents:

Older posts


About this blog:

It is an active abuse of repo.or.cz, letting gitweb unpack the objects in the current tip of the branch blog, including the images and the RSS feed.

Publishing means running a script that collects the posts, turns them into HTML, makes sure all the images are checked in, and pushes the result.

This blog also serves to grace the world with Dscho's random thoughts on and around Git.


Google Ads:
Tuesday, 9th of November, Anno Domini MMX, at the hour of the Rooster

Fun brainstorm session about "Users' Git Helper", a potential new porcelain

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:

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:


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.


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 COMMAND --help" would be an alias to "ugh help COMMAND". 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 branches

shows the branches. Make a new branch from the current state:

ugh branch create BRANCH

Make a new branch from another state:

ugh branch create BRANCH from OTHER-BRANCH

where the other branch can be a local or a remote one. If there are more than one possibility, the command asks you.

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

ugh branch move onto 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 me 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.


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"? This is exactly the problem, because the technical details are different. The very same details the users could not care less about. The very same details the users should not need to care about.

Friday, 11th of June, Anno Domini MMX, at the hour of the Goat

New msysGit imminent

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.

Monday, 8th of February, Anno Domini MMX, at the hour of the Goat

Trying to get more time for msysGit

Nowadays, the msysGit project is driven forward mostly by Heiko Voigt, Erik Faye-Lund, and of course the invaluable mingw.git work of Hannes Sixt. The new-SVN, MinGW-SVN and MinGW-Python projects have stalled. The latest msysGit release is months old.

It does not help that certain people on the Git mailing list write looooong emails that nobody with my schedule can hope to read, rather than being nice and spending some time to phrase what they have to say in a concise manner.

Oh well. I will just concentrate on JGit and msysGit instead of upstream Git, if I get some Git time.

Wednesday, 2nd of December, Anno Domini MMIX, at the hour of the Monkey

Avoiding to get angry

Despite many intelligent people realizing that the recent change to special case http, https and ftp was a terrible decision, it seems that there is enough resistance left on the Git mailing list to keep the brain-dead current state.

The Git mailing list is definitely giving me more grief than joy these days.

Sunday, 18th of October, Anno Domini MMIX, at the hour of the Goat

Git will never be user-friendly

Recently, encouraged by quite some private encouragement, I thought I could take on the task of teaching the core Git developers how user-unfriendly Git is, and that they should be more open to change (especially given that 1.7.0 was already announced to be a version that breaks recent expectations, something I would have expected to merit a 2.0 -- but who am I anyway?).

It is quite ironic, in a very cruel sense, that those people who are such big fans of educating the users instead of fixing their tools are unable to be educated about something that should be obvious.

Yes, I am bitter.

Wednesday, 7th of October, Anno Domini MMIX, at the hour of the Rat

GitTogether in Berlin

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.

Sunday, 9th of August, Anno Domini MMIX, at the hour of the Rooster

The dilemma of being correct

So I am opinionated. No news there. The problem of being opinionated, though, is that people do not take you seriously even if you are correct.

For example, I vividly remember having had concerns about the Git wrapper being linked to cURL, and I vividly remember that our maintainer did not have such concerns and took Daniel's patch. I could not find proof of my public comment quickly enough to add a link here, though.

Alas, there are serious problems with being correct:

  1. If you're correct, you waste a lot of time trying to convince people (but they ignore you nevertheless),
  2. Other people are regularly p*ssed off, especially when they find out (or even worse, when it is pointed out to them) that they were wrong, and
  3. You can buy nothing for having been correct.

It is a lose-lose situation.

In the current context, I am pretty certain that the rev cache and the pack index are so similar in nature that we'll find quite a few issues that we had with one repeated with the other.

As I hate losing time over a discussion others try to "win" -- which invariably means that they refuse to be convinced of anything disagreeing with their opinion ☺ -- I will just shut up, and probably have one or two odd feelings when it turns out I was right.

Friday, 19th of June, Anno Domini MMIX, at the hour of the Monkey

The GraphGUI project

After a few unfortunate delays (and some fortunate ones, just not for us), the GraphGUI project finally takes off. A quick first glance:

The delays were a bit unnerving, but the student is really bright and still has the chance to pull the project off.

Next plans are to show text, too, to invent a rudimentary layout engine that can be adjusted manually (this is in contrast to gitk or log --graph).

After that, integration into JGit (this probably triggered the eGit/JGit split).

And then we'll go wild!

Friday, 15th of May, Anno Domini MMIX, at the hour of the Dog

Wasting way too much time on msysGit

I recently got into the bad habit of spending a large amount of my waking hours working on msysGit, more than is really healthy for me.

For example, I spent the whole morning -- when I should have worked on a very important day-job project -- on trying to fix issue 258, where git web--browse does not work as expected because of quoting issues with cmd.exe.

This is reducing my Git time budget to negative numbers, so much so that I cannot even work on Git projects that I actually like, such as jgit diff or git rebase -i -p, or at least projects I felt obliged to continue to work on, such as git notes.

Now, some people who tried to teach me some time management strongly criticized me for ignoring their lessons, and unfortunately, I have to agree.

The problem is that I would hate to see msysGit fall to the same state it was after I stopped working on it last year. I started it, and I would like it to grow, but too few people took care of the issue tracker, too few tried to debug their problems themselves, too few submitted fixes.

I note, though, that there is a positive trend. But being the impatient person I am ("2 seconds is my attention span") I tend to want the trend to be more impressive.

Anyway, no work on msysGit for at least 4 days, that's what the doctor (me) said...

Monday, 11th of May, Anno Domini MMIX, at the hour of the Rat

Working on jgit diff

Shawn did so many useful things that I use on a daily basis that I felt really awful when I realized just how long I had promised to clean up that diff implementation I wrote for JGit.

Alas, it appears that the thing turned out to be almost a complete rewrite, as the original implementation walked the edit graph in a rather inefficient way.

A little background: Myers' algorithm to generate "an edit script" works on the edit graph: imagine you have all lines of file A as columns and all lines of file B as rows, then the edit graph is a connection of the upper left corner to the lower right corner, containing only horizontal, vertical or diagonal elements, where diagonal elements are only allowed when the lines of both files agree at that point:

 H E L L O , W O R L D
L    \
O        \
W            \

The shortest edit path minimizes the number of non-diagonal elements.

Myers' idea is to develop forward and backward paths at the same time (increasing the number of non-diagonal elements uniformly), storing only the latest end points. Once the paths meet, divide and conquer.

In theory, it would be quicker to store all end points and then just reconstruct the shortest paths, alas, this takes way too much memory.

My first implementation did not remember start or end of the non-diagonal parts, and had to recurse way more often than really necessary (in the end, we will order the non-diagonal parts into horizontal and vertical parts anyway, so start and end are sufficient).

The current progress can be seen here.