Git again


Just a couple of points.

1. Mirroring

The mirror can automatically push updates to the top level repo when it “receives” a “package”, by adding a hook script named post-receive with the command “git push”.

But there doesn’t seem to to be a corresponding pre-send script which can perform a “git fetch” which will update the mirror before people pull from it.

Of course, we can add a hook to the top level repo, but this is bad because

  • The top level repo should not have to know about who is mirroring it
  • it creates a loop
  • our top level repo is in the DMZ (yes, ok, but: I didn’t do it; it seemed like a good idea at the time; and yes we know it needs to be fixed) and cannot initiate connections to the local net

2: Merging

In any sccs, sometimes a “real” merge will be required. Managing this and minimizing the amount of manual intervention required is kind of the whole point. In these circumstances, a repo cannnot perform a “fast forward” merge.

The way this plays out is that users A and B clone node 12345, the repo ‘branch1’ node. A and B both checkout branch1, make changes, creating checkins A23456 and B23456.

A does a push of node A23456 – his new branch1. The master repo does a fast forward: branch1 is now A23456.

B tries to do a push. Doesn’t work, becauyse A23456 (the repo brach1) can’t be fast-forwarded to B23456.

So. The process is that B fetches from the repo. On B’s machine,
heads/branch1 = B23456
remote/origin/heads/branch1 = A23456

B merges A23456 into B23456, creating B34567. This process may involve manual intervention (but shouldn’t if A’s and B’s project manager P hasn’t assigned them to attempt to work on the same bits of code simultanteously.)

heads/branch1 = B34567
remote/origin/heads/branch1 = A23456

B then performs the push. A23456 can be fast-forwarded to B34567 ok, and everything is sweet.

This is how working in a team always goes: before you check in, you pull any changes from the repo and merge them and test that the thing still compiles and runs.

I worked on a job with a large team, once, using Visual Source Safe (it was a while back). We had a big duck made of cane. The duck sat prominently in the cubicle of the most recent person to break the build – who checked in changes without testing that the make still ran to completion.

The simplest way to force pushes to be fast-forwardable is for evreyone to work on a different branch. At work, even though I’m the only one working on AFD at the moment (mostly), I always create a branch labelled with the JIRA id. Likewise, all checkin messages are prefixed with the JIRA. (What happens if I don’t have a JIRA? I sit on my hands until someone creates one, or create one myself. When making changes to an existing production system, you don’t start work until someone with the authority to do so writes down what work they want done.)

Although this solves the mechanical problem, it merely defers the real problem: integrating people’s work, which is sometimes unavoidably and necessarily a manual process, even to the point of “oh shit, we are going to have to rework this entire section of code” if you are Doing It Wrong. Developer’s tasks should not overlap. This means that the structure of a system inevitably reflects the structure of the project that built it. If you have three teams, you’ll get a three-pass compiler. Although this is silly, the problem is that it’s inhumanly difficult, it’s infeasible, to do it any other way. This relates to agile processes and feature-driven design.

The way to do it right is to keep changes in one part of the code, reintegrate your branches when its reasonable to do so, and if any task requires changes across the entire codebase then check everything in and no-one touches anything while that task is being done (also: any task that touches everything is a sure sign that you are Doing It Wrong).

(please note: nothing that I have said here is anything other than common knowlege and practice).

3. Rebasing

Ha ha ha! No girl, I haven’t Gone There Yet. I get the impression that rebasing can create ginormous grief, but that grief is a sign that the project is not being properly managed, that developer’s tasks overlap in wrong ways, that there are miscommunications about when something is “finshed”. AKA: “Oh shit! You can’t rebase that yet, I still have two days of work to do on the branch!”

More to come, I suspect.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: