81–90 of 98 posts
A mucher better explanation of git interals: https://git-scm.com/book/en/v2/Git-Internals-Git-Objects It is surprisingly simple and efficient. I am starting to think this Linus guy knows what he is doing.
He offloaded the complexity to its users! :-) If the command and option names had just been sensible, it would be a lot easier to learn and use. Half the usability difficulty, maybe more, is just this.
How it's done internally, as much as it's remarkable, is just an implementation detail. The fact that users are repeatedly being referred to docs/books, points to conceptual inconsistencies or mismatches in the intended application contexts.
As a user I operate with directories and files. Now version control also introduces a time-component, which is versions (and version of a version aka branch) and some kind of history/timeline/journal/log.
Why would a branch have a "head" and "base", isn't parent/child concept expressive already? Why "ref", if we've got "version" already? Why "stage", "index", "cache"? Why "cherry-pick" if we've got "patch"? Etc.
Understanding what git is doing under the hood did more for my ability to use it effectively than it did for most tools. That said, this document in particular does not seem to be a very good way to get that understanding, it's a very "IBM documentation" way of presenting git. I wish I remembered what I read, because it's was a much easier read.
I found the Git section of "The Missing Semester of Your CS Education" to be helpful.
The important thing to understand is that git is a blockchain
Earlier quoted context omitted.
> Are you really shocked that someone would make a backup before doing something they are unsure of? No, but I'm shocked git is so misunderstood that this would be considered a time to do this. Keeping a backup of previous versions is git's raison d'être . If you can't trust git to do this, how can you trust "cp" to make a copy of a file? I would love to get a genuine answer to my question: what do you think git is f…
> If you can't trust git to do this, how can you trust "cp" to make a copy of a file? I would love to get a genuine answer to my question: what do you think git is for and why do you use it? This would help me enormously to understand where you are coming from. All of us - at some point - were new to git and coming from other VCS systems meant there was a relatively steep learning curve. I also understand git fear -…
He's not new to it. He says he's been using it for over 10 years!
Earlier quoted context omitted.
"Zipping the folder" and keeping a copy of it is literally the sole purpose of a version control system. These kind of comments baffle me, quite honestly. But that is my fault, not yours. Could you tell me what you think git is for and why you use it?
> Could you tell me what you think git is for and why you use it? Maybe it's not your intent, but you're coming off as a bit of a git yourself. He lacks your confidence.
But why? I'm trying to learn here. I'm know I'm autistic and don't understand anyone. It's clear that there's a huge difference in how I perceive git versus how a lot of people apparently perceive it. I'm trying to understand how other people perceive it but nobody will tell me!
Earlier quoted context omitted.
> Are you really shocked that someone would make a backup before doing something they are unsure of? No, but I'm shocked git is so misunderstood that this would be considered a time to do this. Keeping a backup of previous versions is git's raison d'être . If you can't trust git to do this, how can you trust "cp" to make a copy of a file? I would love to get a genuine answer to my question: what do you think git is f…
> No, but I'm shocked git is so misunderstood that this would be considered a time to do this. You shouldn't be. As you say, you shouldn't need to do this, but the fact that so many people do feel the need to do this speaks to poor UI design on git's part. There are, I think, two main reasons why people feel the need to do this. The first is that git makes it really easy to rewrite history, without really offering mu…
It does, I just think they are not obvious enough because people haven't read an article like the one posted here.
Git is an append-only data store. You can't lose anything as long as you have committed it. Rebasing does rewrite history, but it doesn't delete the old history. It's still there. The reflog links to it. The old remote tracking branch links to it. You could even leave a tag there to link to it. There are many ways to get back.
Earlier quoted context omitted.
Why does any post discussing _any_ aspect of git always results in these type of comments? "git is complex", "git command line is confusing me", "life would be easier is we all used subversion". Please let us discuss git in peace. (Although I admit that this one was funny)
>Why... Because lots of people don't want to learn git. They want to bungle through it the same way they bungle through most of the software they touch. People who work with software professionally are very adept at bungling. Even through complicated professional software that other users would need training for. But git is resistant. Even rote memorization won't let you hide completely from learning git. There's a s…
It's been over a decade and I still find this joke amusing: > @wilshipley git gets easier once you get the basic idea that branches are homeomorphic endofunctors mapping submanifolds of a Hilbert space. * https://twitter.com/agnoster/status/44636629423497217 (It's a 'spoof' on the Monad joke.)
For example, ```git-dissect-tipdissects indexed local tips from all noted downstream upstreams, remotes commit graphs, etc.```
Anytime somebody is confused or stuck with Git, it's a great idea to helpfully send them some documentation links from there.
Git's CLI is it's greatest weakness. Someone should really just scrap that part and rebuild it from scratch on sane ground.