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 p
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 think about the way you want changes to get "pushed" to the public repo so others can "pull" them.
Things can get pretty complex with GIT too, where you pull from one repo, branch, do your work and commit, then push to another repo. But it's this flexibility that gives you lots of control over how your development process works and how your source configuration management solution supports that.
Personally I suggest the CLI interface to GIT for a number of reasons. First, it's portable. If GIT runs on that system, the CLI will be there. Second, it helps you to keep track of what's going on with GIT because you are forced to type in things, instead of just letting the GUI do it for you. I also have the TortoiseGit GUI installed on my windows system, but I rarely use it for anything but the most simple steps.
I suggest you start by hammering out how you want your software development process to work, then hammer out what GIT commands you need by using the above web page. Try a number of scenarios with multiple developers and make sure you know how to make GIT work in that environment.. Test it to be sure your process works, then stick to the formula you come up with.
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: (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 p
Re:Abstraction (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 think about the way you want changes to get "pushed" to the public repo so others can "pull" them.
Things can get pretty complex with GIT too, where you pull from one repo, branch, do your work and commit, then push to another repo. But it's this flexibility that gives you lots of control over how your development process works and how your source configuration management solution supports that.
Personally I suggest the CLI interface to GIT for a number of reasons. First, it's portable. If GIT runs on that system, the CLI will be there. Second, it helps you to keep track of what's going on with GIT because you are forced to type in things, instead of just letting the GUI do it for you. I also have the TortoiseGit GUI installed on my windows system, but I rarely use it for anything but the most simple steps.
I suggest you start by hammering out how you want your software development process to work, then hammer out what GIT commands you need by using the above web page. Try a number of scenarios with multiple developers and make sure you know how to make GIT work in that environment.. Test it to be sure your process works, then stick to the formula you come up with.