4 ms·

To be precise, Git makes merges easy, not merge conflicts, which is what you're talking about. Handling merge conflicts automatically is AI-complete. But many S

by wrs 17y ago

To be precise, Git makes merges easy, not merge conflicts, which is what you're talking about. Handling merge conflicts automatically is AI-complete. But many SCM systems make even straightforward merges difficult.

guelo 17y ago
Well then I REALLY don't get it. I can branch and merge all day in my scm if there aren't any conflicts. Is all the hype over git just because maybe the branch and merge commands are slightly simpler?
- deleted 17y ago
  [deleted]
- DarkShikari 17y ago
  No. Read this: http://whygitisbetterthanx.com/ http://whygitisbetterthanx.com/ I would say the primary "hype" factor of git is because of local commits and all the infrastructure/features around them. Better server-side merges is just a nice bonus.
- kowen 17y ago
  Git helped us out a lot in that it tracks content, not files. So where one person might do some cleanup that included renaming some files, and another might make some changes to the same files our previous source control system either choked or just ignored the changes. Also, we were spending a very large amount of time waiting for merges to complete. Minutes. Lots of them. Git is lightning fast, and we spend a lot less cycles waiting (or context switching).
- silentbicycle 17y ago
  Having a local backup of the repo and making branching/merging very cheap reduces the friction in several VC operations. You can use techniques such as bisect* without cumulative network latency disrupting your train of thought. Also, when throwaway branches are cheap, you'll probably find you use them quite a bit more. * For finding what commit introduced a bug, by binary search. Flag a revision as the last known good commit, then bisect will switch to a one in-between, wait for you to test and mark it as good or bad, then repeat. Better yet, just provide a test suite and it will classify the revision automatically. It's somewhat comparable to incremental programming with a REPL, rather than a compile-link-test cycle. Sure, you only get feedback on your code "slightly faster", but that makes a tremendous difference. Git is hyped pretty hard (software hipsters seem to be gaga over it, probably in part because of gasp Linus), but if you ignore all that, it is a pretty good version control system.

by wrs 17y ago

guelo 17y ago

Well then I REALLY don't get it. I can branch and merge all day in my scm if there aren't any conflicts. Is all the hype over git just because maybe the branch and merge commands are slightly simpler?

deleted 17y ago
[deleted]
DarkShikari 17y ago
No. Read this: http://whygitisbetterthanx.com/ http://whygitisbetterthanx.com/ I would say the primary "hype" factor of git is because of local commits and all the infrastructure/features around them. Better server-side merges is just a nice bonus.
kowen 17y ago
Git helped us out a lot in that it tracks content, not files. So where one person might do some cleanup that included renaming some files, and another might make some changes to the same files our previous source control system either choked or just ignored the changes. Also, we were spending a very large amount of time waiting for merges to complete. Minutes. Lots of them. Git is lightning fast, and we spend a lot less cycles waiting (or context switching).
silentbicycle 17y ago
Having a local backup of the repo and making branching/merging very cheap reduces the friction in several VC operations. You can use techniques such as bisect* without cumulative network latency disrupting your train of thought. Also, when throwaway branches are cheap, you'll probably find you use them quite a bit more. * For finding what commit introduced a bug, by binary search. Flag a revision as the last known good commit, then bisect will switch to a one in-between, wait for you to test and mark it as good or bad, then repeat. Better yet, just provide a test suite and it will classify the revision automatically. It's somewhat comparable to incremental programming with a REPL, rather than a compile-link-test cycle. Sure, you only get feedback on your code "slightly faster", but that makes a tremendous difference. Git is hyped pretty hard (software hipsters seem to be gaga over it, probably in part because of gasp Linus), but if you ignore all that, it is a pretty good version control system.