F=hub the 'hub' ADC

a home grown 'hub' for git repos

This ADC (admin-defined command) helps collaboration among repos. The name is in honor of github, which is the primary host for gitolite itself.

[Note that github is a web-based service, and does a lot more, like comments, code reviews, etc., none of which are possible here. We're only talking about some basic stuff to make the most common operations easier. In particular, this system is not a replacement for normal project communications like email!]

Conventions used: all through the following description, we will assume that Alice has a repo parent, Bob has a fork of parent called child, and he is asking Alice to pull a branch he made called b1 from child to parent.

In plain git (without using github or similar), the pull request process starts with an email from Bob to Alice, followed by Alice running a git fetch <Bob's URL> b1 (optionally preceded by a git remote add for convenience of long term use). Until this happens she can't see much detail about the commits to be pulled.

What this ADC does is (a) collect all the pull requests she needs to look at in one place, and (b) allow her to examine the changes with any combination of git log and git diff options without having to fetch the content first, and (c) act as a trusted intermediary to allow Alice to fetch just one branch from Bob even if she does not have any access to Bob's repository!

In a situation where there may be lots of requests, being able to take a quick look at them (and possibly reject some), without having to pull down anything at all, could be very useful.

Once past that level, she could get the changes down to her workstation using git fetch as normal. With this ADC, however, she has another alternative: get them over to parent (her repo) on the same gitolite server, then later do a normal git fetch [origin] to get it to her workstation. This has the added advantage that other people, who may be watching her repo but not Bob's, now get to see what Bob sent her and send comments etc.

general syntax

The general syntax is

ssh git@server hub <hub-command> <args>

Bob's commands

The following commands do not cause a fetch, and should be quite fast:

Alice's "just looking" commands

Alice's "action" commands

Notice the sequence of Alice's action commands: it's either 'reject', or a 'fetch' then 'accept'.

what next?

At this point, you're done with the hub ADC. However, all this is on the bare parent.git on the server, and nothing has hit Alice's workstation yet! Alice will still have to run a fetch or a pull on her workstation if she wants to check the code in detail, use a tool like gitk, and especially to compile/test it. Then she decides whether to accept or reject the request, which will have to be communicated via email, of course; see the second para of this document ;-)

Finally, note that Alice does not actually need to use the fetch subcommand. She can do the traditional thing and fetch Bob's repo/branch directly to her workstation.

note to the admin: configuration variables

There are 2 configuration variables. BASE_FETCH_URL should be set to a simple "read" URL (so it doesn't even have to be ssh) that almost anyone using this server can use. It's only used in producing the git fetch command mentioned just above.

GL_FORKED_FROM is set to gl-forked-from by default, but if your initials are JM you can set it to kde-cloned-from to save time and trouble ;-)