Git bisect (2006)
yarchive.net
Git bisect (2006)
1–10 of 13 posts
Re: Git bisect (2006)
#2"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."
Re: Git bisect (2006)
#3[deleted]
Re: Git bisect (2006)
#4This 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.
Re: Git bisect (2006)
#5"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
If you understand Git branches, this analogy one may help you to understand topology.
Re: Git bisect (2006)
#6"Light cone" isn't what it sounds like (to me): https://en.wikipedia.org/wiki/Light_cone
Re: Git bisect (2006)
#7This 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)
Re: Git bisect (2006)
#8"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
Wow, that would be a great way to respond to all of the people who think git is too complex. :P
Re: Git bisect (2006)
#9This 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 experienc…
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.
Re: Git bisect (2006)
#10This 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.
...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.