Multifaceted Git Update Post

By jefferai|Git, KDE|7 Comments

I haven’t blogged about updates to the Git infrastructure for a while and it’s *long* overdue, so here goes. There’s a lot and I don’t have much time so I’ll keep things brief. Credit for these items go to the sysadmin team as a whole plus Sitaram (the Gitolite author)…

anongit servers

We now have two anongit servers (the second one will be coming online on Monday or so — it’s 95% done). It is very likely that git:// and http:// protocols will be restricted to the anongit servers for better load balancing, so if you have been using git://git.kde.org/… as your clone URLs, please switch those to git://anongit.kde.org/… URLs. Wait, did I just say http?

http protocol support

The anongit servers support pulling/cloning via http. This is using the newer Smart HTTP support in which the Git protocol is run over HTTP via a special server. All pushing must be done via SSH (port 22 or 443) on git.kde.org.

trash/destroy

There are now two systems of deleting your personal clones/scratch repositories.

• unlock/destroy: You can destroy a personal repository, at which point it is gone forever; however, for safety you are now required to run the “unlock” command on the repository first.
• trash: You can trash a personal repository. When you do this, it will be saved for 28 days in case you change your mind. You can use the “list-trash” command in order to see the repositories you have in the trash.

More details can be found in the Git(.kde.org) Manual.

who-pushed

There is now a “who-pushed” command that, given a SHA1 and a repository, can tell you what user pushed that SHA1 to the repository. This is essential for auditing, since commit authorship information can be faked. Now, if a problem arises, we at least can know who introduced that malevolent commit into the public repository.

Repository nicknames

Remember my last post about short Commit URLs? One thing I wanted — and was much requested — was a way to have a more friendly repository identifier. Now they exist. If a friendly identifier exists for a repository, it will automatically be used in the commit URL that is generated. If you want a friendly URL, let the sysadmins know. (We need to figure out a way to make nice names for repo names longer than 8 characters — or just remove that artificial restriction.)

Clones path change

When we first started out, clones would live somewhere like clones/amarok.git/mitchell/myamarok. Why the “.git”in the middle  (we were asked a lot)? Because the path was meant to match the actual name of the repository as it exists on the server.

The reason for *that* is that Git uses a “.git” suffix on repositories that are bare, to make it clear that it’s a Git directory. However (as we found out from Sitaram), this is not supposed to be user-facing, which is why if you use a Git URL with “.git” at the end of it, it’s dropped in the folder that actually is created on the client. So either the path has to lie about the original path on the server, or the client/user has to be made aware of it when it doesn’t really need to be.

What we ended up doing is removing that “.git” from the middle of the repo name (so now it’d be clones/amarok/mitchell/myamarok) and also took pains to ensure that when clone URLs are shown to the user, they are shown without a trailing “.git”.

At the same time, Sitaram made changes in Gitolite to better handle (in the various commands and in the built-in functionalities) cases where the user uses does or does not use the “.git” suffix so that it works correctly in each case.

Updated permissions on master repositories

Master repositories now allow users to create new branches; however, deletion requires the chosen repository manager(s) to intervene.

Updated permission granularities on personal repositories

Personal (clones/scratch) repositories now have a greater level of permission control settable by the user. (The git.kde.org user manual is not yet updated with this information.)

These are now the permission levels that the user can set, from least to most:

• All: everyone has read and basic write permissions on each repository
• Writers: writers can write new branches to the repository
• Managers: managers can also delete branches from the repository
• Dangers: people designated as dangers (to the repository!) can also rewind/force push to the repository
• Creator: the creator always has full rights

projects.kde.org tree view

If you check out the projects page on projects.kde.org (here) you’ll see that it now supports a tree view matching the structure of the KDE repositories. The URLs also match this structure.

projects.kde.org last activity indicator

On the same page (here) you’ll see that information about the last commit for that project is now shown next to each project.

…aaaaaaaaand we’re done.