161–170 of 275 posts
It really says something about the design and documentation of a tool when you need a (far more complex and energy-intensive) Artificial Intelligence to be able to use it without making too many mistakes.
Earlier quoted context omitted.
> The disconnect between git's beautiful internal model of blobs, a tree of commits, and pointers to commits, and the command line interface is so wild Something I heard somewhere that stuck with me: git is less less of a Version Control System, and more of a toolkit for assembling your own flavor of one.
> Something I heard somewhere that stuck with me: git is less less of a Version Control System, and more of a toolkit for assembling your own flavor of one. That's how it is in principle, but it seems to me that there aren't that many different CLI "porcelains" in practice. Kind of like how Knuth figured people would essentially write their DSLs on top of plain TeX, not spend most of their time in giant macro package…
I think that's because most of the people that make custom tooling to support particular workflows build it into graphical (including IDE extensions, web-based. etc.) frontends, not CLIs.
We should start recommending UIs as the default way to learn Git. It would solve a third of these problems and another third wouldn't even come up. If you later decide that the CLI is faster, go ahead. But first, people need to see visually how they can interact with the tree. I like fork.dev, but most clients are pretty similar at this point.
Interactive tutorial with tree visualization that has helped co-workers: https://learngitbranching.js.org/
One of the beauties of Git is that as long as you’ve created an object, it’s impossible to lose that work (short of nuking the .git directory). Committing often is key. Precommit hooks (that take more than ~100ms) go against that.
I have had git corruption problems on a raspberry pi sd card, usually I just had to reclone/abandon that folder
Earlier quoted context omitted.
The thing is if you merge immediately into master and have conflicts, you solve the conflict and only then you can merge. But then the conflict resolution sits at the merge point with a weird default commit message and is hard to decipher. A nicer way is merge master into your branch, with the rebase option (you can set that option as the default). This will put your changes on top of the master changes that happened…
Merge main into your branch, then merge --no-ff your branch into main. No need to rebase or squash anything.
The same problem GP was trying to avoid is created here, the merge conflict resolution being on the merge commit.
Git is one of those technologies that I never got to wrap my head around of, because in so many ways it doesn't follow intuition and unless you have been using it for a long time, for literally every action you would probably have to Google or use the man page of the command.
I can see how it would be a much bigger learning curve if people come straight to git, but it's still hard for me to understand where the blocker is that so many people complain about using it...
Earlier quoted context omitted.
I'm happy I didn't have to scroll too far to see this. Git's CLI isn't elegant, but it really isn't that big of a deal if you understand the basics of what a commit is, what a branch is etc. I struggle to understand why so many devs decide to treat it like mysterious arcane sorcery instead of just spending the needed time on learning how it works. The same can be said about regexes. Regexes and git are probably the t…
>I struggle to understand why so many devs decide to treat it like mysterious arcane sorcery instead of just spending the needed time on learning how it works. For example: you have bazilion ways to achieve the same thing, all of them having its own quirks/advantages? It is just poorly designed, that's it, lol. I like to joke that if somebody else invented Git, then it'd be 10% less powerful, but 10 times more user-f…
It's like complaining about languages ("English is hard to spell and doesn't have consistent pronunciation" etc.), they're constantly changing and that kind of thing is going to happen eventually...
Earlier quoted context omitted.
And that sounds like you failed to understand me. I didn't say "don't use branches". I said "all branches are remote". Pushing to a branch is communication with other human beings. Mixing your own private state into that is confusing and needless in 99% of situations (and the remaining 1% is isomorphic to "you're a maintainer curating branches for pushing to other people at a well-known location"). All branches are p…
> All branches are public. What actual problem does this solve? For me, WIP branches only ever get pushed up if at least one of two things are true about them: 1) They're actually worth preserving, and not some experimental garbage that ended up being totally pointless. 2) I need to get them off of my local machine for disaster-recovery purposes. > If you need to manage local state, do it manually with tags (or stash…
That seems naive. You don't know what's pointless for years, usually. Can I tell you how many times I've gone back to stale pull requests and topic branches to recover "How did I do this?" code?
> 2) I need to get them off of my local machine for disaster-recovery purposes.
That's called a "backup", and yes, data robustness is a big advantage of this workflow. You're acting like this is some kind of rare event. I push my local work to a branch (or three) on github every hour!
A corrolary is hardware independence, btw. Working off remote branches means I can also stand up a replacement development environment with a simple clone. (And the corrolary to that means that I can trivially document this such that other people can stand up development environments for my stuff, too!)
We should start recommending UIs as the default way to learn Git. It would solve a third of these problems and another third wouldn't even come up. If you later decide that the CLI is faster, go ahead. But first, people need to see visually how they can interact with the tree. I like fork.dev, but most clients are pretty similar at this point.
The cli is faster if you know by heart but a real disadvantage is that it is hard to "see" what you did or what happened in the past. Good look finding where/whether an old branch got merged and find out if it is part of a release, using cli.