Git is the simplest, low friction, low cost, low everything above file storage. How can there be something simpler atop an existing file system (I know there are some versioning file systems but I've never used them). I use git for practically anything I do. I to git init and I have my project versioned and I can but don't have to even add messages to each of my versions. You don't have to use anything else if you don't want to but you have so many options if you need them. You don't have to even use git on line if you don't want but if you do there are multiple (even open source) git repositories with free private repos. What is there not to like?
Mercurial is wonderfully simple, particularly for smaller teams. Also, not being able to throw away branches ensures the project maintains a history of some wrong paths that were pursued.
What garbage collection? Isn't staging area actually a feature? I've never used anything else since when I started needing something like 5 years ago git was already a recommended choice, but I also never felt like I needed anything else.
If your commits are not referenced by a branch or tag, then those are eventually committed. Having to have a branch to keep the commit around means you need to come up with a name for it if you ever want more than one name. When I go back to Mercurial, it's actually quite relieving to not have to come up with a short name to describe what the current work branch is doing, only commit messages.
And no staging area is strictly simpler than having a staging area, which is contrary to your assertion.
It's not that I don't know what work I'm doing, it's that I don't know how to give it a unique name.
Sometimes, I try a few different approaches to make something work. Each of these attempts is a different branch--I might need to revisit it, or pull stuff out of it. Good luck staring at a branch name and working out if it's landloop or landloop2 that had the most working version of the code.
Super late, but I think a good approach would be to use an issue/work tracker of really any flavor (even manually), log all of your to-do headings as issues, and then just name each branch after the associated issue/job number.
Other version control software has way simpler syntax and workflow. Subversion for example. The complexity of git makes total sense if you indeed have a complex, multi-HEADed project like the Linux kernel. But most software isn't Linux.
> "Mercurial (hg commit) or SVN (svn commit), or hell, even CVS (cvs commit)."
Why would I [re]learn those tools if I already know git?
If I'm going to move to a new VCS, it's going to be one that actually gives me something I didn't have before, like Fossil. Not some other VCS that captures the same concepts with a slightly different cli UX (which hardly even impacts me at all, since I rarely interact with such systems on the command line rather than through porcelain provided by an editor extension.)
Sure, I'm not saying they're more difficult, but people here are saying that git adds too much complexity in simple projects. It doesn't, but it lets you expand into the complexity if you ever need it in the future.
You've misinterpreted you finding git to be difficult as everyone finding it difficult, leading to an argument based on git being difficult that will never be compelling to those who didn't find learning git to be difficult. I'm one of them - I don't have any CS training - and so are the interns and new starters who use it without complaint in my workplace.
If you are forced into using it to everything but still haven't taken the steps necessary for understanding it, why is that my problem?
I agree - I even use it for tiny personal projects that I don’t even push anywhere because you can instantly get version control with a single ‘git init .’ in a directory. It’s plenty scalable and has very little overhead...
I agree. I have reasonable familiarity with git but I find that traditional SVN-type systems often (not always) have a lower cognitive overhead.
If I ever need to manage the codebase for a huge, multi-level project involving large numbers of geographically dispersed developers then I'm sure I'd use git. For simpler projects, not so likely.
Sure. But you know what is more complex than git? Git + <anything else>.
If you use git at all, you may as well use it for everything. If you have control over which version control system to use, there's no good reason to actively use multiple ones at the same time.
I use git at work where branching matters, I also use git for home projects where git add/commit/push/pull are the only commands I use. Git is efficient at both scales, it is opposite of overkill.
How is git overkill? Perhaps you're conflating Git and Github? Or perhaps you're confusing git best practices or methodologies with git functionality?
Git costs nothing to use, you add it to a project and then it sits there until you do something with it. If you want to use it as a "super save" function, it'll do that. If you want to use it to track every change to every line of code you've written, it'll do that too.
I know people like to complain about git's interface, but is it so lacking to the point that it justifies the time spent on learning multiple version control systems?
Go easy on yourself and stop forcing yourself to use the CLI tools if you dislike them so much. For every editor and IDE under the sun, there exists extensions for these version control systems that provide you with a nicer interface than the CLI interface of any VCS.
For years probably 99% of my interactions with git, or any other VCS, is through editor extensions like magit or fugitive.
Branches in SVN are such a pain! If I recall correctly, creating a branch in SVN consists of making a full copy of everything (remotely, usually). In Git, creating a new branch consists of creating a new pointer to an existing commit.
Git is overkill for so many projects, I hate being forced into for everything.