After a fresh rebuild and ‘make install‘, git gui upon starting up would insist on making me choose a repository, even when I start it from a perfectly valid git working directory.

So I found out that it was failing to execute “git rev-parse” during startup, which was due to /usr/local/libexec/git-core/git-rev-parse being installed with mode 750. And that was traced back to the fact that I have umask set to 0027, so the locally built git-add would have mode 750. Since git uses hardlinks to install all the built-in commands, everything hardlinked to git-add would have the same mode, and I end up with bunch of git built-ins owned by root and inaccessible to anybody else.

So the workaround is either ‘chmod o+rx ${git-source-root}/git-add‘ before ‘make install‘, or ‘sudo chmod o+rx ${prefix}/libexec/git-core/*‘ after ‘make install‘.

Jeffrey drives to his point by giving an example:

And then he states:

"This can be a good design or bad design depending on your needs. We are coupling to an interface, INavigator, but we are also coupling to a specific implementation class, MissileNavigator.

"If MissileLauncher can't do its job without MissileNavigator, then this coupling makes sense, and the class should be tested together with MissileNavigator.

Well, I am not sure about that. Looks to me, the commitment of coupling is already made right on the second line of the code above: where _navigator is declared INavigator. It essentially asserts that:

1. The interface exposed via INavigator suffices for MissleNavigator.
2. MissileNavigator makes no further assumptions on the class that actually implements INavigator.

Once that commitment is made, specifically instantiating _navigator to an implementation class buys us absolutely nothing, and loses for us most of the flexibility associated from programing against INavigator the interface. Think about it this way, if MissileLauncher has to use the specific implementation, MissleNavigator, meaning at some point it will have to explicitly cast _navigator to MissleNavigator, then that would be a very awkward OO design, and we might as well declare _navigator a MissleNavigator, and program against that interface to begin with.

So, depending on how people look at it, the hard-coded instantiation in the constructor can be considered part of the design or the implementation. But either way IMHO it's a bad one, and makes some unnecessary coupling.

The general idea of this approach is to maintain two separate branches -- one for synchronizing with the rest of the world, and the other for managing the local changes -- and sync between the two using the powerful git-rebase.

1. Say we have just cloned the team repository:

       master
       v
   A-B-C

2. The next step is getting ready to start hacking locally:

   (Nadeem Bitar points out below that "checkout -b" is a better way. Thanks!)
   $git branch local && git checkout local
   $git checkout -b local
   $make whatever local changes
   $git add <the files changed>
   $git commit -m 'LOCAL_HACKS: my env'

   Now we have (* indicates we are currently on the local branch, and the L? commits are the ones containing local changes):

       master
       v
   A-B-C-L1-L2
            ^
            local*

3. So we stay on the local branch, continue to work on the real cool features that we are here to really implement, and keep committing just like usual. After a while, we end up with:

       master
       v
   A-B-C-L1-L2-E-F
                 ^
                 local*

4. This is where the interactive rebase comes in so we can move the local changes L1 and L2 to the tip of local:

   $git rebase -i master
   (use our favorite editor to rearrange the commit lines)

   Now we have:

       master
       v
   A-B-C-E'-F'-L1'-L2'
                   ^
                   local*

5. The last step is to bring master up to speed with only the commits we intend to publish:

   $git rebase local~2 master  # local~2 is F' in this scenario.

   So the end state is:

            master*
            v
   A-B-C-E'-F'-L1'-L2'
                   ^
                   local

An alternative is use git-cherry-pick to move the non-local commits from local to master. Although it's easier than the approach above only when there is just one or two commits that need to be moved over.

As the latest version number, 0.4, implies, ditz is still at an early stage, but the idea of distributed issue tracking and managing the issues themselves as part of the codebase sounds very interesting to me.

The Agp440.sys Hang
Since VirtualBox supports the VMDK file format, it's fairly simple to get started: just create a new VirtualBox vm, make it as close to the Vmware one as possible configuration wise, attach the same VMDK files to the vm as harddrives, and that's it.

Although the first time when you try to boot it up in VirtualBox, Windows is very likely going to hang right away. Trying to boot it into safe mode reveals that the sequence hangs at agp440.sys.

It is easily resolved by following this VirtualBox wiki article. Basically boot into the Recovery Console, and disable the agp440 service.

The Mup.sys Hang
Next Windows hangs at Mup.sys. The same trick from above doesn't help. After disabling Mup.sys, Windows hangs at the driver before it. So it's not Mup.sys itself, but something afterwards. Google finds me this virtualbox ticket. Following the tips, I switch to the PIIX4 setting for the IDE controller, experiment various combinations of APIC and IO ACPI, and am able to get past Mup.sys with both enabled.

Reactivate Windows
Finally I'm able to boot into Windows, but with various new hardware found, the Reactivate Windows screen shows up. I called Microsoft to reactivate, but looking back, I would advise waiting until after you have successfully reconfigured windows, especially the network connection (see below).

Hardware Configuration
Once booting into the desktop, Windows happily reports "new hardware" found and offer to install drivers for them. Always choosing the easiest option (i.e. the one with "automatic" in it) gets me through. If it does not for you, try selecting "Install Guest Addons" from the virtual machine menu first.

Naturally I decide to reboot at this point. Big surprise! Windows hangs up again as soon as the splash screen shows up. Booting into safe mode works, but not the normal mode. After a few tries and some futile digging around, I decide to call it a day.

Well, the next day when I try it again, it just magically works! I still don't know how exactly, except maybe a soft reset in VirtualBox is not such a "clean" restart compared to completely quit VirtualBox and restart from scratch.

Network Configuration
The networking doesn't work after booting into Windows at this point. Try to manually add a network connection manually does not go anywhere. Look through the Device Manager and find that the Vmware network card is still in there, with a big question mark. Uninstall that. Force the Device Manager to detect new hardware. Sure enough the VirtualBox one comes up and the driver gets installed smoothly.

Everything works great now. I'm for sure making a baseline copy of the virtual machine though.

So here is the "fun" with do {} while(FALSE);

[edit - 04/30/2005] since my original post, the developer of Yankee Clipper has created a more powerful commercial version, YCX, which charges a meager $14.95. The freeware verion, YC3, is still accessible from the same web site.