5 ms·

> This looks good at first, but just keep in mind the added complexity to this approach. I think this is not exactly right. The approach is fundamentally diffe

by yoha 13y ago

> This looks good at first, but just keep in mind the added complexity to this approach. I think this is not exactly right. The approach is fundamentally different but not more complicated. I think that the one important concept of Git is that everyone has a complete copy repository, making the communication with a server (through SSH, HTTP or the Git protocol) just an additional feature: the very core of Git does not depend on anything.

egil 13y ago
It is also important to note that the git tooling has matured a lot over the years. In the beginning, people used wrappers such as Cogito - "Human-suitable Interface for Git"[1] because the command line interface was such a pain. [1] http://git.or.cz/cogito/ http://git.or.cz/cogito/
einhverfr 13y ago
It is more complicated, and the complexity buys you (assuming you need it) an ability to relax certain limits of more traditional SCM solutions. To be honest I don't find git to be better than svn for a lot of work, having worked with both. There are fundamentally different decisions made, such as: 1 it is a lot easier to forget to add a file in svn, but it is a lot easier to accidentally include a file you don't want in git. 2 workflow in svn is a lot more streamlined because you aren't dealing with a multi-stage synchronization between your repositories (I am assuming the reason you use version control is in part to collaborate). Now, one thing I have started to get really into has been the combination of github and svn, which gives you a lot of the benefits of svn and git together. Now, it doesn't give you every benefit of git but it gives you enough of them to make things easier all around in many cases.
- chris_wot 13y ago
  I really don't understand why you believe it's more complicated. Why do you say that?
  - einhverfr 13y ago
    ok: Workflow with svn: 1. Edit some files. 2. svn commit -m "commit message" (ok, I add an svn up && before, but I consider that one step). done Workflow with git: 1. Edit some files 2. git commit 3. Review the message to see which files I actually want to add, if there is anything that needs to go into git ignore, etc. 4. Edit .gitignore as necessary 5. git add * 6. git commit -m "commit message" 7. git push So for simple cases you have 3 times as many steps, for more complex cases you have more steps. Note that I usually push/pull from my own github repo and not a central one because that avoids a lot of other hassle (and then use pull requests for managing inter-repo changes, something github has done a nice job with). Additionally absent this you have a significant likelihood that you end up with various files that aren't a part of your build environment (generated makefiles, backups of generated makefiles, built packages, etc) accidently pushed out to your central repo.
    - adekok 13y ago
      Only if you make git that complicated. Steps 2-6 can be replaced with: git commit -m "commit message" file1 file2 ... When you use a tool inefficiently, don't blame the tool.
      - einhverfr 13y ago
        That's still a lot more verbose than svn and even if you do that, you still have only managed to reduce the number of commands required from 3x to 2x what svn requires. Also wouldn't you agree that git has a much steeper learning curve than svn? What is this due to if not the added complexity?
        janvidar 13y ago
        1) Edit some files 2) git commit -a -m "blah blah" 3) git push So, it adds one extra command to push things to an upstream git repository. But, this is the nature of being decentralized.

by yoha 13y ago

egil 13y ago

It is also important to note that the git tooling has matured a lot over the years. In the beginning, people used wrappers such as Cogito - "Human-suitable Interface for Git"[1] because the command line interface was such a pain. [1] http://git.or.cz/cogito/ http://git.or.cz/cogito/

einhverfr 13y ago

It is more complicated, and the complexity buys you (assuming you need it) an ability to relax certain limits of more traditional SCM solutions. To be honest I don't find git to be better than svn for a lot of work, having worked with both. There are fundamentally different decisions made, such as: 1 it is a lot easier to forget to add a file in svn, but it is a lot easier to accidentally include a file you don't want in git. 2 workflow in svn is a lot more streamlined because you aren't dealing with a multi-stage synchronization between your repositories (I am assuming the reason you use version control is in part to collaborate). Now, one thing I have started to get really into has been the combination of github and svn, which gives you a lot of the benefits of svn and git together. Now, it doesn't give you every benefit of git but it gives you enough of them to make things easier all around in many cases.

chris_wot 13y ago
I really don't understand why you believe it's more complicated. Why do you say that?
- einhverfr 13y ago
  ok: Workflow with svn: 1. Edit some files. 2. svn commit -m "commit message" (ok, I add an svn up && before, but I consider that one step). done Workflow with git: 1. Edit some files 2. git commit 3. Review the message to see which files I actually want to add, if there is anything that needs to go into git ignore, etc. 4. Edit .gitignore as necessary 5. git add * 6. git commit -m "commit message" 7. git push So for simple cases you have 3 times as many steps, for more complex cases you have more steps. Note that I usually push/pull from my own github repo and not a central one because that avoids a lot of other hassle (and then use pull requests for managing inter-repo changes, something github has done a nice job with). Additionally absent this you have a significant likelihood that you end up with various files that aren't a part of your build environment (generated makefiles, backups of generated makefiles, built packages, etc) accidently pushed out to your central repo.
  - adekok 13y ago
    Only if you make git that complicated. Steps 2-6 can be replaced with: git commit -m "commit message" file1 file2 ... When you use a tool inefficiently, don't blame the tool.
    - einhverfr 13y ago
      That's still a lot more verbose than svn and even if you do that, you still have only managed to reduce the number of commands required from 3x to 2x what svn requires. Also wouldn't you agree that git has a much steeper learning curve than svn? What is this due to if not the added complexity?
      - janvidar 13y ago
        1) Edit some files 2) git commit -a -m "blah blah" 3) git push So, it adds one extra command to push things to an upstream git repository. But, this is the nature of being decentralized.