That was only a very rough version. His original plan was to use it as a backend for other VCS. Torvalds handed over the maintainership of the project to Junio Hamano after about 4 months. Much of what we know today as git are contributions from him and others.
None of this is to say that Torvalds didn't invent it. He invented the content addressed object storage format. But it's important to understand the actual history of git's evolution.
Ya this article was great. I wish I could convince my coworkers to take a deep dive into Git. I do it probably once a year and it's helped me be the "hero" with confidence several times.
Git is exciting/interesting to me....it is not normal.
I just took a stab at git worktree at work this week after rereading this article. It's amazing. We were in the process of upgrading our UI component library and I was able to checkout pre/post upgrade branches without having to continuously npm install to swap between dependencies.
Plus I'm pretty sure I could have both "versions" of our repo locally running at the same time so I could do UI comparisons...but I didn't actually get that far.
They're mixing and messing definitions and concepts and separation together and then get confused because of it. It describes a behavior analysis discovery but lacks the useful, valid discovery. I don't think this is useful for others to read, and detrimental for git newbies, because it's more difficult and confusing than helpful.
git says HEAD defines the current branch
rebase is a process operating on commits and branches - it breaks out of the simple "current repository state" because there's a process and process state around that. They notice things being different, but fail to elevate their view or discover that they have to interpret it differently.
bare repository has no workspace - as such, workspace commands won't work, and there is no workspace current branch. HEAD defines the default/main branch.
And they never ger into the got worktree subcommand and probably don't know you can have multiple things checkedout at once in a different Dir but still all pointing to the same local git clone.
Also with them you can have a bare repo with multiple worktrees at once. Have been working this way for a few months now and it is very nice when switching branches as that becomes a simple cd instead of a git switch or checkout. Which means you don't need to stash any pending changes before you switch branch.
Is goddamn amazing! I had a very large multi-branch project that somewhere somehow had some crashing bug. Instead of searching through 5 or so branches with 20 something large commits for each, I bisected like 7 times and it told me exactly where to bug was introduced.
I love git bisect for complex regressions! If I don't immediately know where a bug is, I write a regression test and then bisect to find where it was introduced. Knowing exactly where the bug was introduced and being able to look at the diff almost always speeds up finding the bug.
For those who don't know (I assume you do), you can git bisect run some_command and git will automatically run git bisect until it finds the falty commit. It's amazing.
I agree. Once we get a hang of the value that bisect brings, one unintended consequence is that we start to value atomic commits a whole lot more. There is nothing more annoying than bisecting a bug and suddenly stumbling upon a commit that does it all: updates dependencies, touches everything under the sun, does cleanup commits for unrelated files, etc. Yuck.
It's so anoying that at $WORK we have multiple git repos with symbolic link that points above their respective .git to each other and need to be in sync. So of course git workree and git bisect don't work that well…
Git
Newest