"To visualise this, it’s simplest to think of the state of your repository as a point in a high-dimensional ‘code-space’, in which branches are represented as n-dimensional membranes, mapping the spatial loci of successive commits onto the projected manifold of each cloned repository."
That's really... good. I have the theory that whether or not you see this is as an attempt at a legitimate explanation or just a joke depends on your level of self-confidence. I think few people will actually understand it (if they do it's a miracle, since such understanding would be a product purely of your own mind trying to interpret sense into what it sees), but those who lack self-confidence will see the fault in themselves, while those with enough confidence upon realizing they don't understand it will realize it's a joke, because if it wasn't they should have understood it.
Of course, now I'm open to a reply that demonstrates that it isn't a joke but makes perfect sense and that I'm clueless and overconfident... :)
This is a revealing peek at the complexity of merged history. You can't project a "git space" onto a line, so a (linear) listing of commits just misleads you into thinking that your history is linear. That complexity is why I always prefer to rebase and keep my history an actual straight line.
TL;DR
- Merging is powerful, but comes with a cost.
- Rebase is your friend. Keep it simple.
Rebasing frequently is nice because it forced you to use Git in a way that makes rebasing pain-free, which leads to nicer Git usage in general.
In my earlier projects when I thought rebasing was evil, it was always because I was abusing aspects of the history that only made everything harder for myself.
(though then again there's surely a million different ways to use a tool like Git, this is all just in my experience)
The team I started on a year and a half ago, first out of college, has the soft requirement that the master git branch for each package be flat. Feature branches get squashed (or rebased into few commits), before being rebased onto mainline. I'm sure there are teams out there that don't like this, since you lose the history from the branches, but this is so great for just being able to _look_ at a history.
I have an alias that's like "git log --oneline --pretty" and a couple other options that I can't remember that gives me the flat graph of history. Digesting that is so much more comfortable, and also makes it significantly easier to understand where I'm at when I'm branching about for feature work.
...well actually... representing an n-dimensional shape as a 2-dimensional line is precisely what the mathematical term "projection" means. My apologies. Accurate phrasing had less punch.
Bisecting with commits that weren't actually tested because no-one ever checked out a tree that literally looked like that is worse, IME. I'd rather embrace the fact that the commits I have to work with are what Bob had on his workstation on Tuesday and what Jim had on his workstation on Tuesday than try to bisect using a "fictional" commit that's actually "what Jim had on Tuesday + Bob's changes up to Friday".
http://tartley.com/?p=1267