...and that's the problem with Git
-
Mike-MadBadger wrote:
There must be something other than weight of users that makes Git popular enough to overcome that learning curve,
The only thing I think that is the cause for its popularity is the geek factor, and it hits several geekoid buttons -- it's: 1. newish and shinyish (anything to make life more interesting for a while) 2. arcane. Geeks love arcane complexity. It's something to yammer on about over cubicle walls, like Design Patterns was in the 1990's. 3. *nix love it because it doesn't need a UI Me, I use the following aging curmudgeon rules: 1. do I have a problem that it solves? NO 2. do I think it can make my life easier even though it has an initially higher level of arcane complexity? NO 3. does the documentation make sense if I read it while playing online poker and surfing Code Project? NO 4. does the documentation make sense if I focus 100% of attention on the docs? NO 5. is it command line? YES - ok, back to the 1980's. I will NOT waste my time on something that does not START with a UI. That said, I'm using it because my client is using it and my client is doing cool things and I, well, I'm also a geek!!!! (but I will never use it on any of my personal projects.) Marc
Latest Article: Intertexti - Resurrecting Apple's HyperCard
My BlogMarc Clifton wrote:
3. does the documentation make sense if I read it while playing online poker and surfing Code Project? NO
:laugh: Great one! Every documentation should pass that test! ;)
-
Mike-MadBadger wrote:
There must be something other than weight of users that makes Git popular enough to overcome that learning curve,
The only thing I think that is the cause for its popularity is the geek factor, and it hits several geekoid buttons -- it's: 1. newish and shinyish (anything to make life more interesting for a while) 2. arcane. Geeks love arcane complexity. It's something to yammer on about over cubicle walls, like Design Patterns was in the 1990's. 3. *nix love it because it doesn't need a UI Me, I use the following aging curmudgeon rules: 1. do I have a problem that it solves? NO 2. do I think it can make my life easier even though it has an initially higher level of arcane complexity? NO 3. does the documentation make sense if I read it while playing online poker and surfing Code Project? NO 4. does the documentation make sense if I focus 100% of attention on the docs? NO 5. is it command line? YES - ok, back to the 1980's. I will NOT waste my time on something that does not START with a UI. That said, I'm using it because my client is using it and my client is doing cool things and I, well, I'm also a geek!!!! (but I will never use it on any of my personal projects.) Marc
Latest Article: Intertexti - Resurrecting Apple's HyperCard
My BlogMarc Clifton wrote:
The only thing I think that is the cause for its popularity is the geek factor
Well, yes, that and Github[^]. It's popularity skyrocketed thanks to Github.
I have always wished for my computer to be as easy to use as my telephone; my wish has come true because I can no longer figure out how to use my telephone - Bjarne Stroustrup The world is going to laugh at you anyway, might as well crack the 1st joke! My code has no bugs, it runs exactly as it was written.
-
...for me anyway (minor rant alert) The Insider News post today, Learn-Git-Branching-an-Interactive-Tutorial[^], really? If you need to explain in that level of detail how to use one of the most basic concepts then something can't be right. OK, I'm no expert at all in version control and maybe 'I just don't get it', (whatever it is), but for love nor money I can't understand how something that's so hard to use gained so much traction so quickly when alternative systems that also have the distributed advantage, are also OS, have better UI options etc. etc. are freely available and are also actively developed etc. Maybe Git just doesn't fit the way my head works but I've seen so many similar comments and there are so many sites offering basic guidance on how to do the most simple things that I'm certainly not alone! What think thee?
Mike-MadBadger wrote:
...when alternative systems that also have the distributed advantage, are also OS, have better UI options etc. etc. are freely available and are also actively developed etc.
For example?
Mike-MadBadger wrote:
What think thee?
Version control in general is difficult. Most 'features' of most version control systems are nothing more than rationalized excuses used to justify a specific one. That said I believe that Git does in fact serve one community very well - the open source internet bound community. Not surprising since I believe it was developed specifically to do that.
-
...for me anyway (minor rant alert) The Insider News post today, Learn-Git-Branching-an-Interactive-Tutorial[^], really? If you need to explain in that level of detail how to use one of the most basic concepts then something can't be right. OK, I'm no expert at all in version control and maybe 'I just don't get it', (whatever it is), but for love nor money I can't understand how something that's so hard to use gained so much traction so quickly when alternative systems that also have the distributed advantage, are also OS, have better UI options etc. etc. are freely available and are also actively developed etc. Maybe Git just doesn't fit the way my head works but I've seen so many similar comments and there are so many sites offering basic guidance on how to do the most simple things that I'm certainly not alone! What think thee?
Git is the first VCS that made any sense to me. Not the first one I used ever, but the first one that did what I needed without requiring me to constantly fight with it to get any of my actual work done. I should probably mention that I use GitExtensions, which perhaps made a significant difference. I've heard good things about GitHub's tool recently as well, so I assume it's progressed quite a bit since I first looked at it.
-
...for me anyway (minor rant alert) The Insider News post today, Learn-Git-Branching-an-Interactive-Tutorial[^], really? If you need to explain in that level of detail how to use one of the most basic concepts then something can't be right. OK, I'm no expert at all in version control and maybe 'I just don't get it', (whatever it is), but for love nor money I can't understand how something that's so hard to use gained so much traction so quickly when alternative systems that also have the distributed advantage, are also OS, have better UI options etc. etc. are freely available and are also actively developed etc. Maybe Git just doesn't fit the way my head works but I've seen so many similar comments and there are so many sites offering basic guidance on how to do the most simple things that I'm certainly not alone! What think thee?
What's interesting to me is that link doesn't seem to work for me. IE it must be too complex for me to understand a site that doesn't say or do anything. I take that back. Looking at the source code http://pcottle.github.com/learnGitBranching/index.html?demo\[[^](http://pcottle.github.com/learnGitBranching/index.html?demo "New Window")] did pop up and manually going to it, it goes through a fast dynamic display of commands without showing what any of the commands mean. The site would be more meaningful if holding the mouse over an image, a dynamic display of the command in action with words saying what actions are taken by the command would be more meaningful and geared to the learning speed of the reader, not the web.
-
Marc Clifton wrote:
The only thing I think that is the cause for its popularity is the geek factor
Well, yes, that and Github[^]. It's popularity skyrocketed thanks to Github.
I have always wished for my computer to be as easy to use as my telephone; my wish has come true because I can no longer figure out how to use my telephone - Bjarne Stroustrup The world is going to laugh at you anyway, might as well crack the 1st joke! My code has no bugs, it runs exactly as it was written.
-
Mike-MadBadger wrote:
There must be something other than weight of users that makes Git popular enough to overcome that learning curve,
The only thing I think that is the cause for its popularity is the geek factor, and it hits several geekoid buttons -- it's: 1. newish and shinyish (anything to make life more interesting for a while) 2. arcane. Geeks love arcane complexity. It's something to yammer on about over cubicle walls, like Design Patterns was in the 1990's. 3. *nix love it because it doesn't need a UI Me, I use the following aging curmudgeon rules: 1. do I have a problem that it solves? NO 2. do I think it can make my life easier even though it has an initially higher level of arcane complexity? NO 3. does the documentation make sense if I read it while playing online poker and surfing Code Project? NO 4. does the documentation make sense if I focus 100% of attention on the docs? NO 5. is it command line? YES - ok, back to the 1980's. I will NOT waste my time on something that does not START with a UI. That said, I'm using it because my client is using it and my client is doing cool things and I, well, I'm also a geek!!!! (but I will never use it on any of my personal projects.) Marc
Latest Article: Intertexti - Resurrecting Apple's HyperCard
My BlogI never understood people's obsession with the command line. I think that under virtually every circumstance, a well organized and well designed UI is always easier to pick up and more productive to use. Certainly more work to develop as well. Whenever I have any significant amount of work that needs committing, it is way nicer to see the list of changes in a UI so I can explicitly see unversioned files, right click and quickly add an ignore pattern if I need to, see if I accidentally changed a file I shouldn't have, double click an entry to pull up a diff easily, etc. I'm a bit of an intuitive design nazi so IMO the command line should be reserved for 1% functionality that is rarely needed.
-
I never understood people's obsession with the command line. I think that under virtually every circumstance, a well organized and well designed UI is always easier to pick up and more productive to use. Certainly more work to develop as well. Whenever I have any significant amount of work that needs committing, it is way nicer to see the list of changes in a UI so I can explicitly see unversioned files, right click and quickly add an ignore pattern if I need to, see if I accidentally changed a file I shouldn't have, double click an entry to pull up a diff easily, etc. I'm a bit of an intuitive design nazi so IMO the command line should be reserved for 1% functionality that is rarely needed.
Mike Marynowski wrote:
I'm a bit of an intuitive design nazi so IMO the command line should be reserved for 1% functionality that is rarely needed.
I completely agree. Marc
Latest Article: Intertexti - Resurrecting Apple's HyperCard
My Blog -
...for me anyway (minor rant alert) The Insider News post today, Learn-Git-Branching-an-Interactive-Tutorial[^], really? If you need to explain in that level of detail how to use one of the most basic concepts then something can't be right. OK, I'm no expert at all in version control and maybe 'I just don't get it', (whatever it is), but for love nor money I can't understand how something that's so hard to use gained so much traction so quickly when alternative systems that also have the distributed advantage, are also OS, have better UI options etc. etc. are freely available and are also actively developed etc. Maybe Git just doesn't fit the way my head works but I've seen so many similar comments and there are so many sites offering basic guidance on how to do the most simple things that I'm certainly not alone! What think thee?
Just wanted to share my experience. We've been using TFS and its associated source control and as dissatisfied as you are with git, I am likewise dissatisfied with TFS's source control (and also visual source safe). I find that it is big, clunky, arcane and I hate that branching requires making a completely new copy of the source code. I dislike that being able to effectively use it requires that I have a central server set up with not only TFS but a SQL Server database. Reverting to previous versions has been a frustrating and error prone experience and there have been all sorts of other annoyances that we've disliked. On the other hand, since we've been using git, the workflow of branching and committing has really clicked with us. git is so much more quick and lightweight (even using the windows version) and it has been so easy to branch merge and commit; it's really been helpful. After I read the first few chapters of the git book by Scott Chacon, I found that sufficient to get started for what we needed. Just like any source control system, it's got its advanced concepts which we may use some day but, for now, we're really enjoying using git. One of our developers is also using the hg-git plugin for Mercurial because that's what he prefers. I don't really like Mercurial. For me, personally, I find it more confusing than git, but if that's what he likes, that's cool. I really like that we can all use what we're comfortable with and still work together. I don't think that so many people have just picked up git because it's trendy. The learning curve would be a damper to that if that were the case. I think that these people have found, like we have so far, that git is a superior VCS. I'm really sorry to hear that you haven't had a good experience with git. Gotta go with what works for you. That's just my two cents...
-
I never understood people's obsession with the command line. I think that under virtually every circumstance, a well organized and well designed UI is always easier to pick up and more productive to use. Certainly more work to develop as well. Whenever I have any significant amount of work that needs committing, it is way nicer to see the list of changes in a UI so I can explicitly see unversioned files, right click and quickly add an ignore pattern if I need to, see if I accidentally changed a file I shouldn't have, double click an entry to pull up a diff easily, etc. I'm a bit of an intuitive design nazi so IMO the command line should be reserved for 1% functionality that is rarely needed.
I like a good GUI too with a BIG emphasis on GOOD. Bad GUIs are horrible. That said... The command line is easy to use in script. This is very important when you want to say, automatically unzip and commit ten things or instantly repeat the last action. If you have a command line you can write a GUI. If you only have a GUI you have to hack the code apart to remove the GUI and create a command line version or add the necessary COM/DBUS interop. A GUI is difficult to make cross platform. A GUI is almost always two to three times as much data as the program itself. More to copy around and longer to start up. A GUI requires design skills and bitmap drawing skills rather than just coding skills. A GUI slows down development of the good parts because they can't be used without including that in the GUI. Command line you add a new verb or flag and you're done.
-
I like a good GUI too with a BIG emphasis on GOOD. Bad GUIs are horrible. That said... The command line is easy to use in script. This is very important when you want to say, automatically unzip and commit ten things or instantly repeat the last action. If you have a command line you can write a GUI. If you only have a GUI you have to hack the code apart to remove the GUI and create a command line version or add the necessary COM/DBUS interop. A GUI is difficult to make cross platform. A GUI is almost always two to three times as much data as the program itself. More to copy around and longer to start up. A GUI requires design skills and bitmap drawing skills rather than just coding skills. A GUI slows down development of the good parts because they can't be used without including that in the GUI. Command line you add a new verb or flag and you're done.
Agreed on all your points. If scripts are useful then your program should certainly be scriptable. As for the rest, yeah, I made the point that it's a lot harder to code something with a GUI front end, especially if its going to be GOOD :) I can understand v0.9beta being CL-only, but after that a respectable tool with any amount of complexity it should have a nice intuitive GUI driving it. I personally like to split my tool projects into a core assembly that has all the functionality, and then reference that from a CL exe and a GUI exe so that none of the UI bloat gets loaded if you are just scripting it.