4 ms·

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

AnIdiotOnTheNet 8y ago
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.
- leadingthenet 8y ago
  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.
  - AnIdiotOnTheNet 8y ago
    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.
    - leadingthenet 8y ago
      How the heck is that simpler than -- git add . -- git commit -m "I did something" -- git push How???
      - joppy 8y ago
        “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.
        leadingthenet 8y ago
        "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.
        joppy 8y ago
        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.
        skolsuper 8y ago
        Most people that _play_ dwarf fortress probably memorise more arcane commands than that, let alone the people that write it.
        seba_dos1 8y ago
        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.
        rcfox 8y ago
        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.
        joppy 8y ago
        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”.
      - BigJono 8y ago
        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.
      - tom_ 8y ago
        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.
        nomel 8y ago
        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).
      - specialist 8y ago
        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.
- Eruvarn 8y ago
  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.
- Cogito 8y ago
  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.
- tom_ 8y ago
  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.)
- nomel 8y ago
  > 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.
  - a_f 8y ago
    Love Tortoise, it is my go to for Git % SVN
- brownbat 8y ago
  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-one-million-developers-exit-vim/ 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.
- imetatroll 8y ago
  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.
- diminoten 8y ago
  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).
  - AnIdiotOnTheNet 8y ago
    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?
    - diminoten 8y ago
      ...or maybe you could use some help!
tom_ 8y ago
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.

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.

leadingthenet 8y ago
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.
- AnIdiotOnTheNet 8y ago
  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.
  - leadingthenet 8y ago
    How the heck is that simpler than -- git add . -- git commit -m "I did something" -- git push How???
    - joppy 8y ago
      “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.
      - leadingthenet 8y ago
        "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.
        joppy 8y ago
        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.
        skolsuper 8y ago
        Most people that _play_ dwarf fortress probably memorise more arcane commands than that, let alone the people that write it.
        seba_dos1 8y ago
        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.
      - rcfox 8y ago
        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.
        joppy 8y ago
        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”.
    - BigJono 8y ago
      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.
    - tom_ 8y ago
      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.
      - nomel 8y ago
        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).
    - specialist 8y ago
      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.
Eruvarn 8y ago
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.
Cogito 8y ago
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.
tom_ 8y ago
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.)
nomel 8y ago
> 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.
- a_f 8y ago
  Love Tortoise, it is my go to for Git % SVN
brownbat 8y ago
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-one-million-developers-exit-vim/ 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.
imetatroll 8y ago
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.
diminoten 8y ago
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).
- AnIdiotOnTheNet 8y ago
  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?
  - diminoten 8y ago
    ...or maybe you could use some help!

tom_ 8y ago

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.