Git is too hard

Mercurial was a pleasure to use, but the "whatever Linus does is great" crowd had to kill it.

> Git is one of those technologies where it's super important to get a good grasp of how to internals work.

I fully agree, that's why I built a tutorial where you learn about Git internals by implementing Git yourself in Python: https://www.leshenko.net/p/ugit/

When I first started using git years ago as a beginner to programming, I always wondered why it didn't just work this way. Since then I've just gotten so used to it that I forgot about my desire for it.

My hacky solution at the time was just to always do anything programming related in a folder watched by Dropbox. Then every single file modification and delta is indeed automatically stored (and away from my machine, for redundancy and safety). It's not the greatest UX when I occasionally dig through the Dropbox file modification history, but it works okay enough.

As an amateur musician, I always wondered why there wasn't any DAW that supported something like this, too. You get an endless undo button that automatically tracks all atomic actions (twist X knob to N%, change Y volume to N dB) to allow for reversions, but no system to actually view, restore, tag, or switch between anything in this edit tree beyond resorting to annoying kluges like "stashing" an older state by spam-clicking "undo", saving a copy of the project under a new file name with a short description of the state at that time, and then pressing "redo" over and over until you're back at the "present".

And when you close the program, all that undo history is gone, in which case if I feel like I did something that really messed up the whole project and which I want to revert, I have to dig through the Dropbox file edit history and download like 10 different copies of the project file around the time I think the undesirable change may have occurred, and load each project one by one to try to find the one that's immediately before that change.

Sorry for the long tangent. I just also don't see why this isn't already a thing for both source code and music project version control.

> See https://stackoverflow.com/a/25028688/8272371 for detailed explanation.

There is a disconnect somewhere. The linked answer says:

> Now, git is different. Git stores references to complete blobs and this means that with git, only one commit is sufficient to recreate the codebase at that point in time. Git does not need to look up information from past revisions to create a snapshot.

> So if that is the case, then where does the delta compression that git uses come in?

> Well, it is nothing but a compression concept - there is no point storing the same information twice, if only a tiny amount has changed. Therefore, represent what has changed, but store a reference to it, so that the commit that it belongs to, which is in effect a tree of references, can still be re-created without looking at past commits.

You can recreate a file that is stored as a root blob plus some series of diffs without looking at information from past commits. But you can't recreate it without doing the diffs! You have to look at the root blob. This is, internally, tracked separately from the commit which created it. But your conclusion:

> when you checkout stuff, git doesn't do diffs to give you the working directory at that point.

cannot be true. If the working directory at that point corresponds to a blob which has only diff information stored, git must apply that diff to a separate blob in order to give you the working directory.

That's like claiming a gun is just used for shooting other things and that the point of the gun is so you don't have to understand how to handle it. Then when you shoot yourself in the foot you get mad at the gun and not yourself.