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.
“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.
Also, pushing your repo to Github / Gitlab / Bitbucket / (a thousand different free services) and then looking at the commit history visually is incredibly difficult.
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.
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.
>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.
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.