51–60 of 821 posts
And honestly, once you understand the concepts of git, you don't need to remember the commands, you need to search for it. Just like you search for all sorts of problems in whatever language you're writing in.
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…
I don't get that either. There have been people here arguing that svn and mercurial were both easier to use than git. But the moment I could import SVN to git I immediately switched to Git for everything. And Mercurial... I guess it's a matter of preference, but I personally never got the hang of it. And the fact that they had both SVN style continuous IDs AND hashes was deeply confusing to me. The only thing I did f…
Earlier quoted context omitted.
‘git checkout filename’ is the equivalent of ‘svn revert filename’
Yes, it works but not intuitive. I mean why use the checkout for the file reversion? And I think that's the problem of git: it's powerful and it works, but it's really not easy to get started.
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…
I too have had to clean up git mistakes of collaborators for years, almost all of them rooted in a misunderstanding of what git does, or carelessness (amplified by git's arguably less-than-stellar naming conventions). But is there really any chance that any DVCS will be "easy" (or "not too hard") for someone who hasn't thought about and internalized what the goal of a DVCS is? It seems a bit like a person who only ever spreads butter complaining that knives are needlessly sharp.
PS: My greatest success rate at converting people from "just hammer git commands until my code is on GitHub" to actually understanding what problem git tries to solve, and how to interact with it, has been from Mary Cook's wonderful Git from the inside out (https://codewords.recurse.com/issues/two/git-from-the-inside...)
I find it a little confusing, especially when trying to do something a little unusual. For example, I had a git repo on a web host and wanted it moved to another host (they cloned it easily enough), but then I wanted to make the cloned repository "authoritative", but I after several hours of looking for an answer I finally gave up. I was able to clone the new repo to my local machine, but I couldn't push changes to t…
But there is a simpler (although less efficient) method. Just simply git clone the new repository onto any machine you want. The clones will naturally be configured to point to that new repository as their upstream.
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 make it bad in some other ways : the the recent youtube-dl debacle.
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 git CLI tool isn't great either -- that's probably the hardest part of git.
Git is one of those technologies where it's super important to get a good grasp of how to internals work. Once you got that, it get easier to answer git questions for others or yourself, and to read the documentation or man pages, as you know what is happening. With how software devs use git, it's 100% worth it to read a good book on it.
If you don't have time for a full book, I think Mary Cook's Git from the inside out is a wonderful start: https://codewords.recurse.com/issues/two/git-from-the-inside...