3 ms·
> My question is why hasn't anyone come along and fixed it? Because the model is simple and easy to understand, and you get a lot of power from understanding i
by cryptonector 4y ago
> My question is why hasn't anyone come along and fixed it?
Because the model is simple and easy to understand, and you get a lot of power from understanding it. Whereas opinionated porcelain that tries to insulate the user from the model will tend to fail in obnoxious ways and will not serve the user.
Really, there's objects, there's commits, then there's a couple of methods for symbolically naming commits (branches and tags) because humans need symbolic names (because we can't memory SHA-1 hashes, or any hashes). Object and commit hashes function as pointers or inode numbers. Symbolic commit names function as hard links.
If you understand the Unix filesystem, you can understand Git.
Everything else follows from these things.
Merges create new objects referenced from the merge commit.
Rebase is just a script around cherry-pick.
Cherry-pick is just applying a delta from a commit and then re-committing.
Everything is copy-on-write except the symbolic names (branch names, tag names).
There -- I've just told you everything you need to know about the model. And all of that trivially carries over to the UI.
- yCombLinks 4y agoThe problem isn't requiring knowledge of the model, the problem is inconsistencies in the git commands for working with the model.
- waynesonfire 4y agoThen create yourself some convenient command aliases. It's not like someone is going to create a layer over git and make it 10x better by fixing some inconsistencies. Plus, whatever benefit is added you'll still have to learn the layer below the abstraction.. eventually.. to be productive. Just not worth it. You may as well learn git. You'll use it for the rest of your career. And that's a breath of fresh air that I can say that confidently about a technology.
- lmm 4y agoIf I've partially staged some changes, why can't I stash and unstash them and get back to the same state? The problems with git are not the commits and the DAG. It's all the ancillary stuff that's inconsistent and confusing.
- fiddlerwoaroof 4y agoYou can, I think, with `git stash push foo.js`
- lmm 4y agoYou can't; depending on the options that will either stash your staged changes to foo.js, stash your unstaged changes to foo.js, or stash both but flatten them so that when you apply them they're all staged (or all unstaged). There's no way to stash it so that you can unstash it and get it back how it is now.
- fiddlerwoaroof 4y agoYeah, I’ve actually found WIP commits and a hook to block them from being pushed end up working better than stashes, so I haven’t spent a lot of time figuring out the complexities of stashes. My workflow here would be something like: git checkout -b save git commit # save staged changes git add . git commit -m WIP # save unstaged changes git checkout -
- cryptonector 4y agoI would either unstage then stash, or commit, create a branch to point to the new HEAD, stash, then reset the branch to the previous HEAD.
- andrewjl 4y agoTo use an example from TFA: how does Reset make any sense based on the Unix filesystem?
- cryptonector 4y ago`git reset` is analogous to filesystem restore from backup. Next question. Note that the analogy to filesystems is not exact. The point is that you can understand higher-level operations in terms of lower level ones / gain insight into higher level operations from knowledge of the lower level concepts. As opposed to the cognitive burden of incomprehensible magic, where every time you get in trouble you've no idea what to do.
- deleted 4y ago[deleted]
- masklinn 4y ago> Cherry-pick is just applying a delta from a commit and then re-committing. That’s trivially not true from its conflict resolution abilities. A cherrypick is a merge which does not create a merge commit, it’s a lot “smarter” that “git show -p | git patch”