Hacker News Reader

Comment by Eruvarn | Hacker News Reader

But if you're going to go through all that work... isn't it easier to just use Git, or some other VC?

I've used git when I've contributed to open source projects. It's an over-complicated mess of a system when you're just one or two devs. Regular backups and notes are more than sufficient and never require you to google how to unfuck your branch.

To jump on the wagon here - at its core git is just compressed snapshots.

Having to 'unfuck your branch' is a result of doing more than just storing compressed snapshots.

This is probably because all the training material and tutorials assume people want to do more than just snapshots, so as you follow along when getting set up it's easy to get into those kinds of situations.

As others have said, doing the compressed snapshot workflow is as easy as adding everything to a git repository, and committing it every time you want to make a snapshot.

The biggest hurdle is having each snapshot 'replace' the current one if you want to go back and look at it, but that's not a hard thing to adjust to for the value you get by using git's machinery for the snapshot workflow:

- fast and efficient remote backups

- greater compression (by using a shared object store for all snapshots)

- easy comparison of different snapshots

- bisection of snapshots to identify when a bug was introduced (including ability to easily automate running tests while bisecting)

- ability to change workflow in the future as needs change, in particular adding in remote collaborators, without having to change versioning system/workflow (well not too much of the workflow)

- rich ecosystem to easily publish source if desired at some point

- and lots more!

Many of these things are possible when you have a list of compressed archives of your source folder, but git really does make it much easier and you don't need to go all in on complex workflows to take advantage of it.

There is a learning curve, true, but it definitely pays off once you are comfortable enough with the (admittedly bad) UI. Even for 1-2 person teams.

I disagree. Compressed backups of the source and a changelog are very simple, straightforward, and effective on this scale. Too many people in this industry fetishize complexity and end up over-complicating even the smallest things, which might be why they get on the internet and criticize someone like Tarn for not doing so instead of actually creating something worthwhile.

How the heck is that simpler than

-- git add .

-- git commit -m "I did something"

-- git push

How???

“git show-me-the-code-as-of-last-Wednesday” is not a command that git understands. Of course, you can _do_ this in git, by memorising arcane commands, and you still only get the output on your terminal. The other option is basically using a GUI interface for git.

On the other hand, finding the folder for last Wednesday and opening it up is easy.

"git log" is a truly arcane command indeed.

Also, pushing your repo to Github / Gitlab / Bitbucket / (a thousand different free services) and then looking at the commit history visually is incredibly difficult.

Come on people, get a grip.

The actual command you need to use is something like “git show HEAD@{2013-02-25}:./file”, which I would count as arcane. And pushing your repo to github and looking at the commit history is using a graphical interface.

No, the actual commands you need to use are "git log", copy the commit ID, and then paste it to "git show <PASTE_COMMIT_ID_HERE>". Of course you can use shortcuts, but those are entirely optional.

For a single-person, single-branch workflow, git is extremely easy. It gets really complicated when doing something more, until you stop seeing git as a VCS tool, but rather as a tool to manipulate the data structure used to do the VCS. But that's a completely different, unrelated topic to this thread.

Most people that _play_ dwarf fortress probably memorise more arcane commands than that, let alone the people that write it.

I've never needed to see the state of the code at a particular date, but I frequently look up when a particular line of code has changed, who did it, and why.

I’m not saying git is bad and you shouldn’t use it, I’m answering the question asked which was “how could anything but git possibly be easier”.

>The other option is basically using a GUI interface for git.

Unless you don't use a GUI for browsing your file system, you really can't dismiss the GUI that comes with Git. It's easy to use the history browser to check out code from certain dates. And it even simplifies tagging commits so you can check out "release 3" instead of referring to a list of release dates.

git log --since=2019-03-06

Windows:

1. Click folder in Windows Explorer

2. Press Ctrl+C

3. Press Ctrl+V

4. Press f2

5. Type new name

6. Press Return

Mac OS X:

1. Click folder in Finder

2. Press Cmd+D

3. Press Return

4. Type new name

5. Press Return

(No real idea about Linux, which I'm only confident with from a programming perspective.)

If nothing else, it's at least fewer keypresses.

This is not really the use case of git. It's not a simple copy. You can look at old changes, reverse old changes, branch and merge new features at a later time.

It's does everything you would need to do manually do with copy paste (diff, merge, find old changes, comment changes, etc) but with much less effort (assuming you use a GUI).

As Donald Norman would say, it's all about the affordances. While supporting almost any inexplicably bad workflow imaginable (git-flow and kin), doing the reasonable thing for a two person crew has way too much cognitive burden.

Because "simple" and "complex" both have two completely different meanings in software engineering. Something can be simple and/or it can be simple to use. Usually they're inversely correlated. You're both working on different definitions of simple.

If there's one of you, whatever, it's your problem.

If thre's two of you, I might be so bold as to suggest it would be worth giving SVN a try. All the usual handy version control system stuff that makes collaboration easier, but the mental model is simpler than git (with all the things you can imagine that might imply), and you've got a handy escape hatch, in the shape of svn lock, for non-mergeable binary files. Great for PSD files and so on.

(Another thing about SVN that's different from git: working copy disk usage is proportional to size of HEAD, not size of repo. You can reasonably use it for distributing binary builds to non-programmer team members, for example.)

Trying to learn git was a humbling experience.

Everything seems so simple and then suddenly you accidentally deleted all your local changes and have a bunch of similar but not identical branches. You get a message saying your head is detached and that feels right. At least your working tree is clean, you'd hate to have a dirty working tree.

You have a pressing need to learn merge but that launches its own fun minigame:

https://stackoverflow.blog/2017/05/23/stack-overflow-helping...

It's so popular and well documented that every time you get confused it feels like a personal failure.

The promise of git is phenomenal, and I know a lot of people realize that by mastering it. I just wish I had figured out a way to learn it more iteratively. It felt like there were a bunch of frontloaded concepts you need to master to get yourself back out of trouble. And if you ask for help from someone who doesn't include whatever you messed up in their normal workflow, even if they've used git for years they might not have any idea.

I have to say that I disagree with you. When I've worked on projects by myself, or perhaps one other developer, I've found git to be much easier to use than making manual backup-folders. There isn't really any need to use that many branches when you're only two developers, so most of the time you're just going to be using git commit, pull and push. It takes about as much time as making backups, and the ability to see exactly which lines where changed in each commit can be invaluable at times.

The ease with which you can review how things have changed in a large code base (one written even by just one person) is invaluable. Not hard to use and the upsides - being able to diff different commits - is really something that shouldn't be taken lightly.

> when you're just one or two dev

Version control has nothing to do with the number of developers, it's a tool used to snapshot code, allowing easy tracking, reversal, and plain old "I'll finish this later". I couldn't imagine trying to develop without being able to make a branch, try something out, jump back and fourth between features, and then merging everything together later.

I can't stand the command line tool, but a nice GUI like Sourcetree or TortoiseSVN makes juggling very nice.

Love Tortoise, it is my go to for Git % SVN

I'm sorry but if you've been writing one of the most complex and elaborate video games in human history, you can figure git out, probably faster than it took Linus to write it (a weekend).

I'm sorry, but if your development model works fine for you and has allowed you to create a cornerstone of gaming culture and keep updating it for nearly 2 decades with a 2 person team... maybe you don't need to take advice from internet know-it-alls?

...or maybe you could use some help!

Copy folder, rename folder... it's fewer keypresses in Windows Explorer than committing to git from the command line! "Using git is less work than copying a folder" is not an argument I personally can get behind.

Reply on news.ycombinator.com