4 ms·

A version control system should be simple. Engineers should be able to focus on getting things to work/done, not battling with a complicated, confusing version

A version control system should be simple. Engineers should be able to focus on getting things to work/done, not battling with a complicated, confusing version control system. Most engineers should be performing two operations/two command s the vast majority of the time: check-in <latest change> check-out <latest version> or <last good version> If a file is new, check-in should ask you if you want to add it to the project. That should be it. The proliferation of tutorials, cheat sheets, books, front end user interfaces like SourceTree for Git is a symptom of a problem. KISS (Keep It Simple Stupid)

rhodysurf 10y ago
Except that doesnt work well for large teams implementing different features in a shared code base. When you have a complex product you may need a complex solution. Which is exactly what git was designed for.
jessaustin 10y ago
One is welcome to use a "Simple Stupid" VCS for one's own projects. Large complex projects, however, need more. That's why git exists, and that's why large complex projects use git. git isn't that hard to use anyway. If you have a problem, just look at one of the many online cheat sheets. b^)
- dispose13432 10y ago
  > If you have a problem, just look at one of the many online cheat sheets. Honestly, I'm too scared to break history, or of clogging it up with commits like "let's see, maybe this will work" "nope, last commit is junk, let's try again","junk","junk","arghh",".","." :)
  - prashnts 10y ago
    > clogging it up with commits like "let's see, maybe this will work" "nope, last commit is junk, let's try again","junk","junk","arghh",".","." :) You can use `git rebase` for this, which lets you pick/remove/merge commits.
    - ashark 10y ago
      ... and you can use trick of copying your .git directory somewhere safe before doing that in case you mess it up, since copying it back to overwrite your mistake is almost always faster than figuring out the "right" way to fix any given mistake, unless you have a really big repo or a really slow disk. :-)
      - dispose13432 10y ago
        Can you keep your .git folder in git? :)
  - jessaustin 10y ago
    You don't have to experiment on the "canonical" repo. Cloning is easy. If you have some code that isn't checked in and you need to experiment to find the particular method you need to use to check it in, just "git diff" to get a diff file you can move around and apply whenever.
peterbonney 10y ago
This is what I used to think. Until I started using it. And mind you I'm not a power user - I'm barely a developer at all. I think the reason that git has this proliferation of tutorials, cheat sheets, etc. is not that it's not easy to use, because (as I've discovered) it is easy to use. No, I think the reason is that people have a pre-conceived intuition of what version control should be, and that intuition is actually wrong. So when they encounter something that does it right (git) it doesn't feel right. The tutorials and cheat sheets help the committed user get over the hump and start to "think git", but if we didn't bring our biases to the party there wouldn't need to be so many of them. As for front-end interfaces, some of that is an attempt to shoe-horn git into something it isn't, which is dumb. But some of it is just adding visual features that are sometimes nice to have and not easily replicated in a terminal.
- dispose13432 10y ago
  For example, how often do you use "staging" (as in not git add .) and how efficient is it's use? In my workflow, you need a feature - you develop, you build, it works, you commit. Because think about it like this, you need a feature. You build, it works, then before committing you notice a bug. You fix it. Now you need to commit in two batches, the new feature and the bug. This is the commonly given reason for the add/commit/push workflow. But at some point it's probably faster to either revert, fix bug, then merge with main than to make your staging precise (especially you don't play with staging in your IDE where you can test code as you type)
  - peterbonney 10y ago
    I'm not sure I follow your example exactly... What works for me (and I am just one person, and - again - not really a professional developer) is that I think in terms of branches. If I want to add a new feature, step one is to create a new branch. I do whatever I want in there, make 1 commit or 50 commits, push to the repo 1 time or 50 times (note that sometimes I might want to push incomplete work so I can load the branch on multiple machines), test in a realistic but isolated environment, fix whatever bugs come up, and generally work however I want to work. Then I merge (or submit a merge request as the case may be) when I'm satisfied. And then I delete the branch, purge it from the repo, may it never be heard from again. If I got something wrong or want to change the work I just submitted, I start over with a new branch. This is certainly not the only workflow, undoubtedly not the best workflow, and maybe not even a good workflow. And it probably breaks down if your changes are sufficiently complicated (though I avoid this by always working in bite-sized chunks, which I've learned to do the hard way). But it works for me and - as far as anyone on my team has ever told me - my colleagues and collaborators. I can't comment on git's other features or alternative workflows - I rarely or never use them! But what I described is functional, simple, and covers 100% of the cases I've encountered in my (brief) career in software. And I think for 99% of users just getting started with git, if they just pick a simple workflow and don't fight the way git wants them to do it, they'd also find that git is surprisingly easy to learn and to use.
dispose13432 10y ago
Well, you need branches (beta, development, release, old-release, etc.)
ubercow13 10y ago
Well, stick to subversion then?
- geezerjay 10y ago
  Subversion: for those who think branching and copying directories around a directory tree is the same thing.
geezerjay 10y ago
> The proliferation of tutorials, cheat sheets, books, front end user interfaces like SourceTree for Git is a symptom of a problem. This is a silly statement. This proliferationi of tutorials only indicates that Git has become a very popular tool and there's a lot of people who decided to take their time to write about it. If you happen to browse through those tutorials, they are essentially all the same, touch precisely the same basic and trivial use patterns, and are devised to help newbies get up and running in no time. Initialize a local repository. Check out something from a remote repository. Commit a change. Create a branch. Mergue branches. Pull from a remote repository. Push to a remote repository... That's all. Very basic stuff. In fact, can you come up with a single distributed VCS that is simpler and easier to use as Git and provides the same level of functionality? No, you can't.
btschaegg 10y ago
This is essentially the attitude i referred to earlier [1]. You don't see the problem git is actually trying to solve and project your own "world view" onto it - that's how you come up with sentences like "A VCS should do X." Version control does consist of more workflows than just yours. If you want to have meaningful collaboration with many people, the model you refer to does not work at all (hell, even in the small team I work in currently, it slows everybody down). If you're not using gits features, use another tool. You're essentially complaining about the UI of a chainsaw, when what you want to use is an axe. Also, if you're forced to use git, chances are either you or the person(s) forcing you don't see the full picture. [1]: https://news.ycombinator.com/item?id=13182911 https://news.ycombinator.com/item?id=13182911

rhodysurf 10y ago

Except that doesnt work well for large teams implementing different features in a shared code base. When you have a complex product you may need a complex solution. Which is exactly what git was designed for.

jessaustin 10y ago

One is welcome to use a "Simple Stupid" VCS for one's own projects. Large complex projects, however, need more. That's why git exists, and that's why large complex projects use git. git isn't that hard to use anyway. If you have a problem, just look at one of the many online cheat sheets. b^)

dispose13432 10y ago
> If you have a problem, just look at one of the many online cheat sheets. Honestly, I'm too scared to break history, or of clogging it up with commits like "let's see, maybe this will work" "nope, last commit is junk, let's try again","junk","junk","arghh",".","." :)
- prashnts 10y ago
  > clogging it up with commits like "let's see, maybe this will work" "nope, last commit is junk, let's try again","junk","junk","arghh",".","." :) You can use `git rebase` for this, which lets you pick/remove/merge commits.
  - ashark 10y ago
    ... and you can use trick of copying your .git directory somewhere safe before doing that in case you mess it up, since copying it back to overwrite your mistake is almost always faster than figuring out the "right" way to fix any given mistake, unless you have a really big repo or a really slow disk. :-)
    - dispose13432 10y ago
      Can you keep your .git folder in git? :)
- jessaustin 10y ago
  You don't have to experiment on the "canonical" repo. Cloning is easy. If you have some code that isn't checked in and you need to experiment to find the particular method you need to use to check it in, just "git diff" to get a diff file you can move around and apply whenever.

peterbonney 10y ago

This is what I used to think. Until I started using it. And mind you I'm not a power user - I'm barely a developer at all. I think the reason that git has this proliferation of tutorials, cheat sheets, etc. is not that it's not easy to use, because (as I've discovered) it is easy to use. No, I think the reason is that people have a pre-conceived intuition of what version control should be, and that intuition is actually wrong. So when they encounter something that does it right (git) it doesn't feel right. The tutorials and cheat sheets help the committed user get over the hump and start to "think git", but if we didn't bring our biases to the party there wouldn't need to be so many of them. As for front-end interfaces, some of that is an attempt to shoe-horn git into something it isn't, which is dumb. But some of it is just adding visual features that are sometimes nice to have and not easily replicated in a terminal.

dispose13432 10y ago
For example, how often do you use "staging" (as in not git add .) and how efficient is it's use? In my workflow, you need a feature - you develop, you build, it works, you commit. Because think about it like this, you need a feature. You build, it works, then before committing you notice a bug. You fix it. Now you need to commit in two batches, the new feature and the bug. This is the commonly given reason for the add/commit/push workflow. But at some point it's probably faster to either revert, fix bug, then merge with main than to make your staging precise (especially you don't play with staging in your IDE where you can test code as you type)
- peterbonney 10y ago
  I'm not sure I follow your example exactly... What works for me (and I am just one person, and - again - not really a professional developer) is that I think in terms of branches. If I want to add a new feature, step one is to create a new branch. I do whatever I want in there, make 1 commit or 50 commits, push to the repo 1 time or 50 times (note that sometimes I might want to push incomplete work so I can load the branch on multiple machines), test in a realistic but isolated environment, fix whatever bugs come up, and generally work however I want to work. Then I merge (or submit a merge request as the case may be) when I'm satisfied. And then I delete the branch, purge it from the repo, may it never be heard from again. If I got something wrong or want to change the work I just submitted, I start over with a new branch. This is certainly not the only workflow, undoubtedly not the best workflow, and maybe not even a good workflow. And it probably breaks down if your changes are sufficiently complicated (though I avoid this by always working in bite-sized chunks, which I've learned to do the hard way). But it works for me and - as far as anyone on my team has ever told me - my colleagues and collaborators. I can't comment on git's other features or alternative workflows - I rarely or never use them! But what I described is functional, simple, and covers 100% of the cases I've encountered in my (brief) career in software. And I think for 99% of users just getting started with git, if they just pick a simple workflow and don't fight the way git wants them to do it, they'd also find that git is surprisingly easy to learn and to use.

dispose13432 10y ago

Well, you need branches (beta, development, release, old-release, etc.)

ubercow13 10y ago

Well, stick to subversion then?

geezerjay 10y ago
Subversion: for those who think branching and copying directories around a directory tree is the same thing.

geezerjay 10y ago

> The proliferation of tutorials, cheat sheets, books, front end user interfaces like SourceTree for Git is a symptom of a problem. This is a silly statement. This proliferationi of tutorials only indicates that Git has become a very popular tool and there's a lot of people who decided to take their time to write about it. If you happen to browse through those tutorials, they are essentially all the same, touch precisely the same basic and trivial use patterns, and are devised to help newbies get up and running in no time. Initialize a local repository. Check out something from a remote repository. Commit a change. Create a branch. Mergue branches. Pull from a remote repository. Push to a remote repository... That's all. Very basic stuff. In fact, can you come up with a single distributed VCS that is simpler and easier to use as Git and provides the same level of functionality? No, you can't.

btschaegg 10y ago

This is essentially the attitude i referred to earlier [1]. You don't see the problem git is actually trying to solve and project your own "world view" onto it - that's how you come up with sentences like "A VCS should do X." Version control does consist of more workflows than just yours. If you want to have meaningful collaboration with many people, the model you refer to does not work at all (hell, even in the small team I work in currently, it slows everybody down). If you're not using gits features, use another tool. You're essentially complaining about the UI of a chainsaw, when what you want to use is an axe. Also, if you're forced to use git, chances are either you or the person(s) forcing you don't see the full picture. [1]: https://news.ycombinator.com/item?id=13182911 https://news.ycombinator.com/item?id=13182911