5 ms·

I wish I could decipher my mental blockage with understanding git's model of development.

by tlack 17y ago

kscaldef 17y ago
I think the mistake you're making is in thinking that git _has_ a model of development. It doesn't. It's an extremely flexible set of tools which you can build many development models and branching strategies from.
- rbanffy 17y ago
  Or, to use a tired image, "There is no spoon".
Sapient 17y ago
It takes a while to fully grok git, but I recently found a really good presentation which has helped my co-workers get up to speed really quickly. The most important tip for understanding git is probably to actually start using it. edit: Forgot the link http://gitcasts.com/posts/railsconf-git-talk http://gitcasts.com/posts/railsconf-git-talk
guelo 17y ago
I have the same problem. Everyone is always saying how easy merging is, but if two developers work on the same code it's going to be hard to reconcile no matter what git can do. Merging is merging is merging. If, for example, I make a change to a file and another developer refactors it out of existence there's no tool out there that's going to automatically figure out the merge. Someone has to sit down and spend some brain cells to figure it out, whether he's using git or subversion.
- 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.
donaq 17y ago
I didn't grok git until I found out that it's just magic. --> http://www-cs-students.stanford.edu/~blynn/gitmagic/ http://www-cs-students.stanford.edu/~blynn/gitmagic/ I found that document rather more useful in getting me started than the official man pages. :)

I wish I could decipher my mental blockage with understanding git's model of development.

by tlack 17y ago

I wish I could decipher my mental blockage with understanding git's model of development.

I think the mistake you're making is in thinking that git _has_ a model of development. It doesn't. It's an extremely flexible set of tools which you can build many development models and branching strategies from.

rbanffy 17y ago
Or, to use a tired image, "There is no spoon".

Sapient 17y ago

It takes a while to fully grok git, but I recently found a really good presentation which has helped my co-workers get up to speed really quickly. The most important tip for understanding git is probably to actually start using it. edit: Forgot the link http://gitcasts.com/posts/railsconf-git-talk http://gitcasts.com/posts/railsconf-git-talk

guelo 17y ago

I have the same problem. Everyone is always saying how easy merging is, but if two developers work on the same code it's going to be hard to reconcile no matter what git can do. Merging is merging is merging. If, for example, I make a change to a file and another developer refactors it out of existence there's no tool out there that's going to automatically figure out the merge. Someone has to sit down and spend some brain cells to figure it out, whether he's using git or subversion.

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.

donaq 17y ago

I didn't grok git until I found out that it's just magic. --> http://www-cs-students.stanford.edu/~blynn/gitmagic/ http://www-cs-students.stanford.edu/~blynn/gitmagic/ I found that document rather more useful in getting me started than the official man pages. :)