
Git bisect (2006) - 99_00
http://yarchive.net/comp/linux/git_bisect.html
======
randomanybody
"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."

[http://tartley.com/?p=1267](http://tartley.com/?p=1267)

~~~
Noseshine
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... :)

~~~
ZeroGravitas
Related:

[https://git-man-page-generator.lokaltog.net/](https://git-man-page-
generator.lokaltog.net/)

------
pwfisher
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.

~~~
2bitencryption
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)

~~~
greyskull
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.

------
jcheng
"Light cone" isn't what it sounds like (to me):
[https://en.wikipedia.org/wiki/Light_cone](https://en.wikipedia.org/wiki/Light_cone)

