Hacker News Reader

Comment by digdugdirk | Hacker News Reader

Any tips for someone outside the industry wanting to up their hobby programming game? Basically just trying to avoid the Useful_Script_v2-Final-Final-ReallyFinalThisTime.py syndrome, and realizing the value of a dated change history.

View on HN

My suggestion would be to not learn git. Go with just about any other version control system if you’re not using it professionally. I’ve used cvs, Subversion (svn), Perforce (p4), and others. Honestly, Subversion and Perforce were both significantly easier to setup, learn, and use than git. While they all have their growing pains, it took me about a week to get used to Perforce. It took me more like a month or two to get used to svn. I’ve been using git for years and still find it very hard to use and strongly dislike interacting with it.

I second Subversion - though only because it is the closest to an open source alternative to Perforce. Otherwise it has a bunch of problems, like three separate half-baked implementations for shelving and aside from TortoiseSVN every other GUI front end has been either abandoned or on life support with a bunch of bugs.

But unless you have to work with other people in places like github, etc, it beats having to bother with git - especially for games that have a ton of binary files (which, unlike what some people will tell you, you want to have both version controlled and in the same repository).

Hell, if you really want a DVCS go with something like Fossil, it is still much easier than git, simpler to setup (just a single binary) and has more features (wiki, bug tracker, forum, etc) that you will find useful anyway.

Though personally the best experience i had with VCS is with Perforce, at least in gamedev: check out the latest version, merge any local changes, make modifications in a changelist, shelve the changelist in case i want to stop working on something and work on something else, use the shelve to send a WiP version to a coworker to merge with his changes (or see if things work as expected) or for code review, etc.

Sadly Perforce seems to be bound in a company that tries to sqeeze it for all its worth, adding a bunch of stuff of questionable usefulness, etc. It'd be nice if there was an open source alternative to it that allowed for the same or very similar workflows, all the issues i had with P4 over the years (e.g. merges between streams) were due to how P4 seems to be implemented, not due to anything inherent in the workflows themselves. There is no reason for an alternative to copy all the bugs.

Hard disagree. Subversion is awfully complex compared to git.

Yes, Subversion is initially easier to learn and use than git. It's not easier to set up as it's client-server while git is fully local. Also Subversion is an incongruous mess.

Subversion's CLI is actually sane and much easier compared to the abomination provided by Git. Additionally, Subversion can be used entirely locally, without the need to deploy and configure any server application.

It seems that you are comparing apples to oranges. Building your own SVN server from the ground up can indeed require some effort. Doing the same for Git demands more or less the same level of effort on your part. So, I believe you are comparing building an SVN server from the ground up to something like installing Gitea or GitLab, or using Git locally.

Again, you don’t have to install an SVN server. Just run `svnadmin create REPONAME` and use the `svn` client to import your data into the repository.

You don't have to set up a database for Git, either, and it works entirely locally. Git init, edit or copy in some files, git add, git commit, boom you're done. Optionally add a remote, push to the remote, pull from the remote if needed. If you're working alone, as I do, this is about 95% of the Git I need. Occasionally I clone to a different machine, or use Working Copy on iOS.

So? You've just described exactly the what's achievable with Subversion. The only missing part is adding remote repositories.

> You don't have to set up a database for Git, either, and it works entirely locally.

What database? Subversion doesn't need any special database to work. Just the repository and its working copy. Both can be local and can be created with two commands.

You're just talking past each other. You were responding initially to another user saying Subversion needs a server, and you responded that it doesn't. A different user responded, thinking your statement meant that you thought Git needed a server.

I disagree (with your advice, not your experience). I'm a total amateur and use Git for versioning prose. It is the only SCM that I can easily use across multiple devices and platforms. I don't use it for complex operations, mostly clone, commit, pull, push, branch now and then. I taught myself to use it from the command line. I guess being curious and persistent helped me get to whatever minimal level of utility I have with it.

I like Perforce it is fairly easy to use.

If you want to go old school there is RCS or SCCS. GNU provides source code (for SCCS there called CSSC). Though *CS are per file not per logical commit.

IIRC Perforce actually used RCS under the covers for storing the deltas.

The main complexities of git really come when you start having to work with other people also editing the same files you are. If you're just doing a solo project, you'll likely be mostly on a single branch, maybe a handful of others if you're experimenting a lot. In that case, you largely just need to know add, commit, push, checkout, and can largely ignore the complexities of merging and rebasing.

You only need to understand {init,commit,diff,status,push} to use git. When something goes wrong you can delete your .git and start new. This obviously not what you want when you have a codebase with collaborateurs somewhere public accessible, but its fine to get used to it.

That's only true if you don't want to undo any changes. What's the easiest way to get back the previous version of function foo() in file bar.py if I already made other commits to the same file, and want to keep those?

Keeping a "bar copy(2) final working.py" file is not about having a nice looking timeline, it makes it very easy to get back to a working state. All you need is copy and paste, or keep the working function as a comment in bar.py. You can see your working code and know you're not messing with it when you're experimenting with bar.py. I'm not saying that's the best way of doing it, but it's a very common use case that's not usually addressed in git guides, where it's all about pushing commit after commit, maybe branching, maybe pushing to a remote with others, but rarely enough focus on undoing mistakes after some experimenting if you didn't branch first.

> What's the easiest way to get back the previous version of function foo() in file bar.py if I already made other commits to the same file, and want to keep those?

You are operating under the assumption that foo() changes in a vacuum. That is an invalid assumption for lots of software changes.

Commits are supposed to contain one logical change each. That logical change may or may not cross function boundaries (often it will).

Reverting a commit should revert the logical change. That is how you accomplish what you're after in git.

I've seen so many people do the "select function body, copy, toggle comment, paste copy of function, try out ideas on this new version" workflow. I've done it plenty too in Matlab and similar during various labs at school. I'm not talking about best practice during software engineering, I'm talking about having the confidence your code can easily get back to a known good state if you want to experiment, like beginners should do a lot of.

And plenty of times functions are self contained enough that you can change the function body without changing other code as well.

Telling someone to "delete your .git" is actually TERRIBLE advice. This should never be necessary unless you go screwing around in .git and break internals. It has a high probability of causing irreversible data loss. It's exactly the worst habit to build if you want to start collaborating.

If your repo ends up in a weird state, learn how to fix it. It should not be terribly complicated, especially if there is no rebasing happening.

The light bulb moment for me learning git, which I don't see get mentioned nearly enough, was this:

Stop thinking in terms of branches, and start thinking only in terms of commits. Pretty much every git operation makes so much more sense when you consider your repo just as a tree of commits (technically a DAG), rather that trying to reason about what it does to the branches. Branches are really just pointers to commits which can change over time, and most git commands don't really care about them.

I think you can immediately get value out of Git, even if you don't understand almost anything. Also there's a lot less footguns if you're not collaborating with anyone else.

Check out the book Learn Git in a Month of Lunches. It's exactly as advertised—only thing to keep in mind is that it was written before the master > main changeover, so depending on your local config you may need to swap that out when you're following along with its exercises.

Reply on news.ycombinator.com