You've somehow managed to originate two insanely useful pieces of software: Linux, and Git.
Do you think there's anything in your work habits, your approach to choosing projects, etc., that have helped you achieve that level of productivity? Or is it just the traditional combination of talent, effort, and luck?
Git is like any tool, it's useful under two conditions.. 1. It's the correct tool for the job at hand... AND 2. The person holding the tool has the necessary skill to use it correctly.
In my opinion, git is a useful tool for the designed function, however, it takes a bit more skill than most tools of it's kind to use effectively.
I think we know what that means if you don't find git useful.... You either are using the wrong tool, or you don't know what you are doing...
If it's hard for a new user of Git to come to know what he is doing, then perhaps some abstraction needs to be created around Git that's easier for the average new user to understand.
I used to have issues with git, but the problem turned out to be that I didn't understand HOW the tool does what it does. It isn't the tool, it's the preconceived notions that folks bring to the table which don't match how the tool works.
You cannot fix this by wrapping git in some wrapper that makes it look like subversion or CVS...
A good abstraction leads a user towards understanding, no matter what his level; a good UI reflects the abstraction, leading the user to use it properly, again, no matter what his or her level.
Git may have good abstractions (I'll take your word for it), but it has no UI to reflect it and so is opaque to many. In my attempts to use git, I've grown tired of wading through shitty web pages all of which give examples of use, but no abstraction description and no description of how these abstractions are to be properly used.
If you could point me to one of these documents that clearly explain git's abstractions and their proper use (actually, I'll take the abstractions only - I can probably work out proper use from that), one hopefully having both Windows and Linux information - professionals sometimes have to use both - I'd appreciate it. Until then, I'll have to be fine with using SVN locally and attempting to avoid git as much as possible.
Also, you need to remember that GIT is designed to be self contained locally and you "push" and "pull" changes to/from public repos. My biggest problem when shifting from SVN to GIT was that all your changes are made LOCALLY to your local repository and not to the common shared repository. That means your commit is only on your local system in that directory tree and no place else. Now if you want to have a shared repository and work with others, you have to carefully th
I just asked myself... what would John DeLorean do?
-- Raoul Duke
Productivity (Score:5, Interesting)
You've somehow managed to originate two insanely useful pieces of software: Linux, and Git.
Do you think there's anything in your work habits, your approach to choosing projects, etc., that have helped you achieve that level of productivity? Or is it just the traditional combination of talent, effort, and luck?
Re: (Score:0, Troll)
Git is actually the opposite of useful.
Re: (Score:5, Informative)
Git is actually the opposite of useful.
Git is like any tool, it's useful under two conditions.. 1. It's the correct tool for the job at hand... AND 2. The person holding the tool has the necessary skill to use it correctly.
In my opinion, git is a useful tool for the designed function, however, it takes a bit more skill than most tools of it's kind to use effectively.
I think we know what that means if you don't find git useful.... You either are using the wrong tool, or you don't know what you are doing...
Abstraction (Score:2)
If it's hard for a new user of Git to come to know what he is doing, then perhaps some abstraction needs to be created around Git that's easier for the average new user to understand.
Re: (Score:2)
What? And make it work like CVS?
I used to have issues with git, but the problem turned out to be that I didn't understand HOW the tool does what it does. It isn't the tool, it's the preconceived notions that folks bring to the table which don't match how the tool works.
You cannot fix this by wrapping git in some wrapper that makes it look like subversion or CVS...
Re:Abstraction (Score:2)
A good abstraction leads a user towards understanding, no matter what his level; a good UI reflects the abstraction, leading the user to use it properly, again, no matter what his or her level.
Git may have good abstractions (I'll take your word for it), but it has no UI to reflect it and so is opaque to many. In my attempts to use git, I've grown tired of wading through shitty web pages all of which give examples of use, but no abstraction description and no description of how these abstractions are to be properly used.
If you could point me to one of these documents that clearly explain git's abstractions and their proper use (actually, I'll take the abstractions only - I can probably work out proper use from that), one hopefully having both Windows and Linux information - professionals sometimes have to use both - I'd appreciate it. Until then, I'll have to be fine with using SVN locally and attempting to avoid git as much as possible.
Re: (Score:2)
Try this: http://www.gitguys.com/ [gitguys.com]
Also, you need to remember that GIT is designed to be self contained locally and you "push" and "pull" changes to/from public repos. My biggest problem when shifting from SVN to GIT was that all your changes are made LOCALLY to your local repository and not to the common shared repository. That means your commit is only on your local system in that directory tree and no place else. Now if you want to have a shared repository and work with others, you have to carefully th