I bet you're smart enough to understand it. Inside, git inside is much more logical and neat that the (unfortunate) historical CLI makes it feel. It's a shame it holds people back from using this very powerful and useful tool. (Once you've reached understanding, switch to magit, gitui, tig, etc, for comfort and speed.)
No, I just don't use it often enough in any other scenarios.
I pretty much do solo work these days, I don't need rebasing or branches or pull requests or anything like that.
I honestly don't really need version control at all but it's a pretty baked-in habit. I thought svn was nice, a good balance of capability and understandability. It worked well in the "central respository" style of the day, which is effectively how I work.
On the other hand I'm quite comfortable with long shell pipelines using find and xargs and awk and other utilities that are at least as arcane as git, so like I said, it's all what you are accustomed to. If I were doing git feature branches, rebases, and pull requests every day at work, I'd probaly feel that they were pretty easy.
A clean history and the ability to roll back to any point is still useful when working solo.
Git bisect is one example of this. If you know roughly when a bug was introduced, you can do an O(log n) binary search to find what commit introduced it.
I don't understand, and maybe you can explain if you are willing, why people use this to indicate speed? It gives no practical reference of how fast or slow that search would be without knowing the real factors involved. Right?
It explains runtime speeds relative to n (size of history, roughly). It doesn’t tell you whether to expect it to take 5 minutes or 5 hours, but it will tell you whether a tool will scale up to large repos or not.
An O(log n) tool will probably work fine on a large repo, an O(n^n) tool will probably have an unusable run time on anything but tiny repos.
I would generally infer that to mean “this will run in an acceptable amount of time on basically any repo”. There isn’t much of a reason to say that it’s O(log n) if it has a run time of 6 weeks when n is 1.
> An O(log n) tool will probably work fine on a large repo, an O(n^n) tool will probably have an unusable run time on anything but tiny repos.
Wouldn't all repositories in use today offer O(log n) speeds though? I would think it's a given just because search has been a solved problem for many decades now. Are there any that search at O(n^n)?
An efficient but naive approach is probably O(n), because it searches the entire history. Runtime grows as history does.
The point of bisect is that it understands each commit as a linear snapshot of the code base, to narrow down the commit that you’re looking for. So if you say that you know commit 1000 is bad and commit 1100 is good, it will ask you to check if commit 1050 is good. If 1050 is good, it knows that the bad commit has to be between 1000 and 1049 so it asks about 1025. If 1050 is bad, same thing in reverse.
A more naive approach would ask the user to check commit 1000, then 1001, then 1002, etc.
I’m honestly not well-versed enough in other version control systems to comment on whether they contain a similar feature or whether users would have to write their own.
It’s not magic that it’s O(log n) so much as that git has a native O(log n) manual search feature.
Agreed. But you don't need git to bisect, any version control system can do that, especially if you're talking about a single file. Git probably makes it easier than some others to bisect the entire project.
I'm speaking more generally than git here, part of being any type of inventor is to simplify for the user and make it intuitive, that way if the internals change, the abstraction/external look the same.
I bet you're smart enough to understand it. Inside, git inside is much more logical and neat that the (unfortunate) historical CLI makes it feel. It's a shame it holds people back from using this very powerful and useful tool. (Once you've reached understanding, switch to magit, gitui, tig, etc, for comfort and speed.)