Hacker News Reader

Comment by qorrect | Hacker News Reader

> but I've never had something as multiheaded as the linux repo.

Git is overkill for so many projects, I hate being forced into for everything.

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?

> I know there are some versioning file systems but I've never used them

But those other systems were the whole point of the post you replied to ;)

> How can there be something simpler atop an existing file system

Mercurial? Similar DVCS concepts, but you no longer have to worry about garbage collection or staging areas...

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.

When would you be creating a branch to do work without knowing what work you're doing?

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.

> Isn't staging area actually a feature?

I've been using git for a few years, and staging has been all cost with zero benefit so far.

"Isn't staging a feature?"

Well yes, but the GP is claiming that git is the most simple thing above file storage.

Staging may be a feature, but it adds complexity. Perhaps useful complexity, but complexity nonetheless.

mercurial with a list of different plugins for each project? no thanks

Why would you need a different list of plugins for each project?

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.

`.git` is a directory, while in Fossil, the repo is a single SQLite file.

Not making any larger comparison here, what I'm saying is that a single file is simpler than a single directory.

care to elaborate? I fail to see how git would be considered 'overkill' for a project.

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.

Subversion needs a server, for one. For a single user and a single file, Git is already less overhead.

It doesn't, actually, you can host a repo on the filesystem without any sort of server process.

http://svnbook.red-bean.com/en/1.7/svn.ref.svnadmin.c.create...

You literally need to know two commands to work with git in a simple project; add and commit. I don’t see how that is any complicated?

By that argument, you literally need to know a single command to work with Mercurial (hg commit) or SVN (svn commit), or hell, even CVS (cvs commit).

git commit -a then.

> "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.

Git is a simple or as complex as you need it to be. And the complexity doesnt come at a cost to anyone who doesn't require it but uses git anyway.

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...

It has such minimal overhead I don't know how you could say that.

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.

Furthermore, if you're forced to use it, it's because you need it to interact with others' versions of the repo, in which case branching matters.

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.

Definitely. I find SVN so much easier. But we must all use Git because cargo cultism is cool, or something.

We use Git because GitHub happened to be the first non-shitty code repository website.

I'm talking about internal repos.

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?

Yes.

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.

How do you work on more than one thing at once with svn without manually managing patch files?

Branches.

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.

Yes, branches look like full copies, but they are sparse copies. So only any changed data on the branch gets actually stored in the repository.

That's basically all it is in SVN as well...

And of course it's remote, every action in SVN is remote since it's centralized (except for shelving).

Reply on news.ycombinator.com