161–170 of 821 posts
Git is hard because it precisely models the complexities of concurrently modifying source code on multiple computers. It explicitly models all of the concepts and operations that are relevant in that domain - branching, merging, my local changes, the server that my local branch is kept in sync with, rewriting local history, rewriting public history. Can you shoot yourself in the foot? Absolutely, because this stuff r…
Earlier quoted context omitted.
I'm not sure I follow your logic: why not take a few days to learn the fundamentals of git? I did that a few years back (and I'm not saying I read the source code, just learned about the base concepts from a few blogs and played around with some more advanced commands), and it has paid dividends _every single day for the last several years_. For example, I avoid tracking branches and have started using `git fetch`, `…
I am limited by time on what I can learn, every day I have five other things I'd rather spend my time learning about instead of git. The "git experts" that I know of are no more productive than me and more often than not do annoying things like rewriting commit histories after I made comments in their PRs, that I'm not convinced it's worth the day or two I need to learn it fully. In the end git is not in production,…
That's exactly what I'd expect someone to do after I commented on their PR.
I don't agree at all. Git is the simplest version control system I've ever used. The concept of merging, rebasing, cherry-picking, and resetting works so naturally that I'm basically going to expect this level of ease of use from any VCS I use going forward. That being said, I know there are some who have trouble with Git. But IMO it isn't because Git is hard, but because they don't have to truly understand Git to us…
Can I use git like a simpleton? Absolutely. Can I gracefully recover from errors in its application? Nope, it never happens. It's a chainsaw and I ultimately have to solve the problem by using it like one.
I don't agree at all. Git is the simplest version control system I've ever used. The concept of merging, rebasing, cherry-picking, and resetting works so naturally that I'm basically going to expect this level of ease of use from any VCS I use going forward. That being said, I know there are some who have trouble with Git. But IMO it isn't because Git is hard, but because they don't have to truly understand Git to us…
>But IMO it isn't because Git is hard, but because they don't have to truly understand Git to use it. That's how easy it is. A copy&paste of my previous comment: Everybody's brain is different but I actually understand all of git's internals (the "plumbing") but it doesn't help me with the git CLI (the "porcelain"). Yes, I know that Git is a DAG (Directed Acyclic Graph), and that HEAD is a pointer, and the file forma…
Earlier quoted context omitted.
I'm not an idiot, but I don't fully understand git. I am coding for a living, and I use git every day. I probably could sit down for a couple of days and fully understand how git works, but I've never needed it, I understand how basic git operations work, and I stay away from commands that I don't understand. With GitHub desktop you don't need to open the command line for any standard operations, I only need to use t…
> I probably could sit down for a couple of days and fully understand how git works This means it isn't hard. If you are capable of understanding algorithms of any complexity you should be able to learn how to use git (and how much of it) without treading on ground that is dangerous for you to use. All of this "it's too hard" rhetoric is infantilising or coddling people who frankly shouldn't be trusted to code anythi…
Besides, nobody is arguing git needs to be made weaker, just that it would be nice if it had a more gradual learning curve. Easy things easy, hard things possible. If you can’t see how git is hard you’ve forgotten what it is like to be a beginner.
Here is another approach: Back in the bad old days before git I was in a 20-30 person company that used Microsoft's SourceSafe. For anyone unfamiliar it had a basic library type structure where only one person could get out (lock) a file at a time. Now the obvious downside is that when someone goes on holiday or simply forgets those locked files can become blockers. The solution to that is to have an admin unlock the…
This is the root of the author's issue. As another commented, git is born in a world where computers are mostly offline, people are highly technical, and will spend a lot of time manually crafting the messages they will send to the numerous collaborators. It is an alone-first software. What the author wants (and exactly what I want as well: https://news.ycombinator.com/item?id=25002318) is the complete opposite: a system that knows it's connected to other people, where changes are instantly propagated and easily visible, where the differentiator between "branches" is not "what computer does it reside on" but "who did it". That's the model behind GitHub, after all.
git is complex because it's working with a very complicated model that is not in line with what most people expect today. As I said in my other comment it seems that fossil works with that flow, but I haven't tried it. However what is sure is that it doesn't make sense to ask git to become what it fundamentally is not.
EDIT: There might be a solution with wrappers. When you look at git-annex assistant (https://git-annex.branchable.com/assistant/) you can see that the right amount of abstraction can provide something closer to what we expect... but at this point it's not git anymore, so we might as well start from scratch.
I don't agree at all. Git is the simplest version control system I've ever used. The concept of merging, rebasing, cherry-picking, and resetting works so naturally that I'm basically going to expect this level of ease of use from any VCS I use going forward. That being said, I know there are some who have trouble with Git. But IMO it isn't because Git is hard, but because they don't have to truly understand Git to us…
So instead of SELECT you'd have FETCH, PULL, CHECKOUT, CLONE, READ, PEEK, and OBSERVE. And each of them could in some cases also modify or even delete the data depending on the switches.
Imagine there was no division between DML and DDL - you just have to remember which option switches change the schema in addition to doing some other things.
And then people would say "SQL is very simple, just learn relational algebra".
That's how I feel about git :)
With SQL I know for sure I can't break the database by doing a select. I know I can't change schema by doing a DML.
With git I'm pretty sure I can't break anything by doing git status, but other than that all bets are off.
Earlier quoted context omitted.
I'm not an idiot, but I don't fully understand git. I am coding for a living, and I use git every day. I probably could sit down for a couple of days and fully understand how git works, but I've never needed it, I understand how basic git operations work, and I stay away from commands that I don't understand. With GitHub desktop you don't need to open the command line for any standard operations, I only need to use t…
+1 These commands will get you 99% of the way: - git status - git branch - git pull - git add - git commit - git diff - git merge - git push - git checkout For everything else there's StackOverflow, but the info in there comes with the risk of being stale. -------------- Edit commit abaeb3b4: Add missing commands and improve formatting Edit commit 842babda: Add git checkout
I don't agree at all. Git is the simplest version control system I've ever used. The concept of merging, rebasing, cherry-picking, and resetting works so naturally that I'm basically going to expect this level of ease of use from any VCS I use going forward. That being said, I know there are some who have trouble with Git. But IMO it isn't because Git is hard, but because they don't have to truly understand Git to us…
>But IMO it isn't because Git is hard, but because they don't have to truly understand Git to use it. That's how easy it is. A copy&paste of my previous comment: Everybody's brain is different but I actually understand all of git's internals (the "plumbing") but it doesn't help me with the git CLI (the "porcelain"). Yes, I know that Git is a DAG (Directed Acyclic Graph), and that HEAD is a pointer, and the file forma…
This was surprising to me, and shows how different people's experiences of git can be. My workplace switched to git from an obsolete centralized VCS earlier this year, and I could easily answer these.
Something like this is probably where the line between those in this thread who agree that git is too hard, and those who think the detractors are just lazy and stupid, runs. Folks, people are more different than you expect!