They should have just called detached HEAD for branchless mode. That's all that it is: HEAD is directly on a commit instead of pointing to a branch. Clearer and less caps lock.
But people also complain about the “branch” term so maybe they would like the more internal “head” term? In which case we're back to square one.
I was replying to a comment about how the fact that Git has a datastructure (or whatever was meant) is surprising since it's just a command that you call, which is absurd considering what it does (store revision history).
Good point about patch-based VCSs. The diff/snapshot thing is definitely an implementation detail for snapshot-based VCS. (I haven't tried out patch-based ones yet.)
> The only thing I'd really adjust in that statement is condensing down the description of trees to "commits are a snapshot of the repository" (as opposed to a diff, which a lot of people seem to think commits are despite it being a niche model in VCS design).
A lot of VCS have used diffs to implement commits. But... they have also used snapshots from time to (every N commits) in order to make checking out old commits more efficient. Apparently this is how Mercurial works and how either Subversion or CVS implements it.
This is based on some article I read yesterday. I could dig it up if this turns out to be wrong.
> Git commits are stored on disk as snapshots, but that's not necessarily how Git treats them! Various Git commands treat a commit as either a complete repo snapshot or as a change set, depending on what you’re doing.
The problem is that the documentation and the developers go between these modes so fluently that you have to know the context in order to distinguish them. Of course to them it's obvious that you are treating the incoming changes as a “changeset” since it's a diff (a patch) from an email (not a snapshot).
This is the “name” section for `man git-rebase`.
> git-rebase - Reapply commits on top of another base tip
How should someone new guess that this means to (effectively) take the diff of each commit and applying those changes? Instead of working on the snapshots?[1] Because I think you could also interpret it as: take the tree (the snapshot) of each of these commits and make an alternative subgraph where the parents are different, propagating from the new base tip. Which means that you can make a new root commit (disregarding old history by “squashing” seems to be popular on SO for some reason) starting from A by rebasing A on `--root`. But it doesn't work like that.
If you want to do that you should instead use git-replace.
In my experience, for every little question about cherry-picking or rebasing, you have to go down to the fundamental concepts. Because the way people work is not like a sponge which only absorbs the information that it is given; people learn 10% about something and then automatically infer the rest, and sometimes 50% of that is wrong. So then you have to unnest that.
I guess this is my long-winded way of agreeing with the author.
[1] Working on the snapshots would also be useful. You could use that to format all of the commits on the branch.
Again, Joel has pointed out a truism: abstractions abstract.
Nothing is leaking. Did someone guarantee that you would get as predictable performance with garbage collection compared to manual memory management? No, because that guarantee was never part of the abstraction.
Those scientific theories are moreso models. Models that get progressively less wrong.
Garbage collection is wrong to the degree that it leads to memory unsafety or memory leaks that are not caused by humans. But using more memory is not a “leak” because it has nothing to do with the guarantees.
It's a nice enough reminder about the limitations of abstractions but the thesis isn't as strong as it is classically regarded to be.
Something that is inherent to any abstraction is giving up control; this is simply necessary in order for the abstraction to have implementation space. Take the example of SQL queries that are slow. The abstraction itself isn't leaky unless the queries give the wrong results sometime. The abstraction isn't some guarantee about the run-time of a query.
An abstraction abstracts away N of M parameters (N < M). Joel would presumably say that N has “leaked”. But more straightforwardly you can say that these concerns have been abstracted away.
Therefore the Law—always a good sign when the original author calls it a “law”[1]—can be restated as: all abstractions abstract.
Can someone explain this to me? America won the Cold War and had an influence on Russia's (the successor state) transition to a market-based economy. Then how can “we“ at the same time be mad about how the transition was handled?
My impression of Suckless is that it’s “Unix philosophy” software where you edit the code and recompile instead of using dynamic configuration like all those config files. And while there are way too many ad hoc app-specific config systems out there, I don’t see how Suckless makes a huge difference for simplifying things.
Oh what ritualistic nonsense. Those developer machines will also have to compile the code and run the application in debug mode, which will make the app slower than on a regular user’s machine if we assume the same hardware.
What?