git rebase /home/you us

(That's "all your base are belong to us" in git-speak)
I think I am starting to get the hang of git.

The key is not to think of "versions" of the codebase, but rather, in terms of "patches". Git is not "version control" it is "patch management".

The rebase command is an excellent example of this, and it is really unusual and powerful (which can make it dangerous).

The best thing about it, is that it allows you to avoid the "shoulda syndrome".

For example, imagine you are working on a new feature. You spot a bug, and fix it on the spot.

In cvs or subversion, you have violated the "shoulda" policy dictated by these tools. You "shoulda" put your current changes somewhere else (or used a new area, I have about 4 local copies of my svn work project).

Now, in order to commit just the fix, you are going to have a lot of pain and suffering to split things out, test it, and commit it, then merge back.

But in git, there is no "shoulda". You can fix that bug, and carry on with life.

How so?

First, you need to get all your changes into patches. Use "add -i" (interactive) to get everything in (add interactive allows you to commit individual lines from a file, if necessary). Then you can use branches to test just the patches you want to commit.

The real power comes from rebase.

Rebasing is confusing (and potentially dangerous), because it allows you to edit the history of the repo.

It is also two different commands in one.

The first command is plain rebase (git rebase <relativeHead>). This is used in place of "git pull" to update a working branch (keeping it relative to that branch, rather than merging).

The second command is editing history (git rebase -i <relativeHead>). This allows you to shuffle the order of patches, and merge patches.

So if the patches to your working area are:
trunk
Start of new feature
Additional feature
More stuff
Bug fix

You can shuffle the bug fix up to right after the branch from the trunk. You can then push that patch into the trunk. Your working area is clean, and you don't have to bother the trunk with all your intermediate commits.

Stuff I've read lately

"B is for Burglar" (Sue Grafton)(audio) - Much better than the previous book. Grafton stays away from the romance novel feel, and the narrator is much better. My only complaint is that the ending is over the top (especially in light of the last book).

git clone harrier

Well, I've started to get a feel for git, and it is not a good feeling.

It is the sort of, hollow, cold feeling you get when you see a Pat bus driving down the street.

I have been reading a lot, trying to figure out what is going on.

For personal projects, it is fine. If a little weird. "git commit -a" (not recommended, but sometimes you want to save some typing) misses new files. git diff doesn't always work right (show me what I've changed), sometimes you need to say "git diff HEAD".

At work, it has been more disastrous.

I admit, the first time, I gave it the hardest possible problem. I branched, then reformatted all the code. The next merge was totally hosed.

Ok, that was a hard problem, I can forgive that (although git seemed even more confused than svn - I find svn merge to be very good, git feels closer to the old cvs merge).

Then, I made some straight forward changes on another branch.

Still I get all sorts of weird merge conflicts.

Ugh.

I have had some success messing around with rebase. Still not convinced it is a good idea...