201–210 of 821 posts
In general as long as you have a clean remote you can fuck around without worry because you can just throw everything away and start over.
Earlier quoted context omitted.
With that attitude, I definitely wouldn't want to work with you either. I also love the assumptions about me and the thinly veiled ad-hominem :-) We should be able to admit that a tool has a crap UI and cut out the macho geek attitude. I've been working in this field for about of 15 years and the amount of needless pain we endure from core tools is unimaginable. I'm waaaay past the learning curve for Unix tools, git,…
I'm really not sure what to say to this. I'm guessing you're not an engineer. It's only product management types that cast around technical criticisms without proposing any solutions so I guess you are of that strain. I don't believe you're stupid, far from it but I think your perspective needs some correction. We've been using VCS fairly universally for the last 25-30 or so. There's been RCS, CVS, SVN, Perforce, Cle…
> of that strain [of people]
> injured animal grandstanding
...
Plus, sooo many assumptions in there. As an engineer, I know that assumptions are bad :-)
I've read this as a rant about why we should want a fancier SVN. Unsurprising coming from someone working at Github, but hardly representative of what git was made for and can actually do. Centralisation is easier, but generally the wrong solution. Git is distributed by design , and most of the difficulties come from that. Github makes git easier by making it centralised, and that makes it easier to use, but actually…
Git also sucks when someone in your team drags their feet and doesn't use it properly. And when your team is mostly made of non pure comp. science background who have learnt SQL on the job, trying to get them to stick to git is really difficult. There almost needs to be something in between that satisfies this kind of intermediate technical ability and interest. I think Atlassian could come up with something suitable…
I studied theoretical physics and learnt SQL for a job (as I'm sure most do) but have no issue with git. In any case, you have to learn how git works to use it effectively. That doesn't come by magic when doing comp sci, as far as I know.
Earlier quoted context omitted.
I hope I never end up working with you bud. “Where is the code?” “Oh I’m sorry I couldn’t do it because it was hard can I still be paid please?”
I refer to my comment from a couple of days ago: https://news.ycombinator.com/item?id=25080013
Unless you mean just VCS for yourself, in which case you could probably just use anything you liked rather than complaining about it ...
And it's not manliness to say that if you can't grasp complexity you really shouldn't be writing code. That's self evident. It's the whole point of what we do. I'm not looking down on people who can't code - but it's horses for courses. To suggest anything else is just bonkers.
First of all, I'm sure the author knows more about git than I do, so I don't wanna come across as trying to lecture an expert. But I do feel that his main point misses the mark. It seems to be centered around the idea that a lot of reasonable people are surprised by things git won't let them do (or, more accurately, strongly advices against doing). The problem is that most of these things are only "reasonable" from t…
Earlier quoted context omitted.
+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
So this, to me, is not a 'benefit of git' it articulates in some ways how bad it is (although very powerful). Most people can get going with those 99% commands quite quickly, the problem with git is any move from the known path creates some pretty amazingly complicated scenarios. And those '1% of the time' commands blow up into time-consuming rabbit holes of complexity. Often, Stack Exchange has several answers for t…
“Git gets easier once you get the basic idea that branches are homeomorphic endofunctors mapping submanifolds of a Hilbert space.” — Isaac Wolkerstorfer http://twitter.com/agnoster/status/44636629423497217
Earlier quoted context omitted.
>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…
Totally agree on the "staging area". I've always thought that the staging area should only activate when you `git add` or otherwise add files to it. If there are no staged files, then git commit should act like git commit -A.
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…
The article has a better way to assess difficulty, based on how easy it is to teach other how to use it.