...and that's the problem with Git
-
...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:
What think thee?
Git is THE most non-intuitive, syntactically klunky (command line, really???) version control systems I have ever had to use. It is confusing, non-intuitive, and frustrating. On numerous occasions I have sat down with the intention of getting productive work done, only to have wasted 2 hours trying to figure out how to get the latest remote commits downloaded onto my local repository, finally giving up, deleting the entire folder, and re-cloning the entire repository. After my Git rant of a few weeks ago, one poster kindly suggested SmartGit/Hg[^] which I downloaded, tried out, and found to be a life saver, and promptly purchased. So yes, that interactive tutorial is absolutely necessary. I still don't fully understand the nuances of branches, commits, stages, stashes, and all the other complexities and bizarre command line syntax nuances that Git forces you to learn -- life was NEVER this complicated with SVN, CVS, or any other version control system I've ever used, going all the way back to RCS in the days of DOS. Happily, SmartGit takes a lot of the pain of Git out of the process. Furthermore, while I understand that people rave about distributed source control, I still do NOT see the point. If you want to share your work with others, you still have to commit to the remote server. I've never in my life needed the complexities of local commits and branches. In my ever so humble opinion, Git solves problems that exist only because Git creates the problem to begin with! Stashes are a great example. I've never in my life needed to use a stash, but stashes exist to solve a problem created by distributed source control, so we have a complex solution because of a "feature." Makes little sense to me. "Cherry picking?" In SVN, that was as easy as right-clicking on a file, reviewing the commits, and picking the version I wanted to extract. Git seems to make simple concepts into demons of complexity. And one final note -- Git's merge, when I had to use it to merge two branches that had evolved over several months, broke a lot of code. In fact, on several occasions, it did some very stupid and inexplicable things, requiring hours of hand comparing to figure out what the merged code should look like (there were probably 50 of these WTF merges to dea
-
...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?
It's an arcane solution to a problem that's been solved by better products. Git rhymes with shit. Go figure.
"I do not have to forgive my enemies, I have had them all shot." — Ramón Maria Narváez (1800-68). "I don't need to shoot my enemies, I don't have any." - Me (2012).
-
...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?
That is why I like Mercurial.
Bob Dole
The internet is a great way to get on the net.
:doh: 2.0.82.7292 SP6a
-
Mike-MadBadger wrote:
What think thee?
Git is THE most non-intuitive, syntactically klunky (command line, really???) version control systems I have ever had to use. It is confusing, non-intuitive, and frustrating. On numerous occasions I have sat down with the intention of getting productive work done, only to have wasted 2 hours trying to figure out how to get the latest remote commits downloaded onto my local repository, finally giving up, deleting the entire folder, and re-cloning the entire repository. After my Git rant of a few weeks ago, one poster kindly suggested SmartGit/Hg[^] which I downloaded, tried out, and found to be a life saver, and promptly purchased. So yes, that interactive tutorial is absolutely necessary. I still don't fully understand the nuances of branches, commits, stages, stashes, and all the other complexities and bizarre command line syntax nuances that Git forces you to learn -- life was NEVER this complicated with SVN, CVS, or any other version control system I've ever used, going all the way back to RCS in the days of DOS. Happily, SmartGit takes a lot of the pain of Git out of the process. Furthermore, while I understand that people rave about distributed source control, I still do NOT see the point. If you want to share your work with others, you still have to commit to the remote server. I've never in my life needed the complexities of local commits and branches. In my ever so humble opinion, Git solves problems that exist only because Git creates the problem to begin with! Stashes are a great example. I've never in my life needed to use a stash, but stashes exist to solve a problem created by distributed source control, so we have a complex solution because of a "feature." Makes little sense to me. "Cherry picking?" In SVN, that was as easy as right-clicking on a file, reviewing the commits, and picking the version I wanted to extract. Git seems to make simple concepts into demons of complexity. And one final note -- Git's merge, when I had to use it to merge two branches that had evolved over several months, broke a lot of code. In fact, on several occasions, it did some very stupid and inexplicable things, requiring hours of hand comparing to figure out what the merged code should look like (there were probably 50 of these WTF merges to dea
Marc Clifton wrote:
Git is THE most non-intuitive, syntactically klunky (command line, really???)
I'm one of those people who likes to use git on the command line - I can specify exactly what I want to do very quickly, especially since I use it within Powershell. But then I'm one of those Powershell command-line nerds, so maybe it doesn't count... When it comes to browsing source and viewing diffs, a UI wins hands down though - but I use a combination of a merge utility and the online viewing capabilities that most git hosts have to achieve that. If you want a UI that does everything then yes, SmartGit wins for sure. I just find it to be quicker and simpler to use the command line for most git operations.
Marc Clifton wrote:
In my ever so humble opinion, Git solves problems that exist only because Git creates the problem to begin with! Stashes are a great example. I've never in my life needed to use a stash, but stashes exist to solve a problem created by distributed source control, so we have a complex solution because of a "feature."
I like distributed source control and the fact that I can check in my code from anywhere, internet connection or not (I have numerous times checked in code for my own purposes while in the middle of a flight), and only push when I get my code to a point where it's ready to do so. Stashes are pretty useful when you need them but often not necessary (and you don't have to stash just because the command-line text suggests it as a possible resolution).
Marc Clifton wrote:
Git's merge, when I had to use it to merge two branches that had evolved over several months, broke a lot of code. In fact, on several occasions, it did some very stupid and inexplicable things, requiring hours of hand comparing to figure out what the merged code should look like (there were probably 50 of these WTF merges to deal with.)
I have seen that on occasion - there are a few bugs here and there in the merge engine that have made me seriously ticked off on the not-so-frequent occasions they have popped up.
Marc Clifton wrote:
Yes, some people say that Git really shines when working with large teams, but I have my doubts. Mercurial is supposed to be far superior.
We used to use Mercurial where I work (team of 5 devs working on the same code) and we found it too limited
-
Mike-MadBadger wrote:
What think thee?
Git is THE most non-intuitive, syntactically klunky (command line, really???) version control systems I have ever had to use. It is confusing, non-intuitive, and frustrating. On numerous occasions I have sat down with the intention of getting productive work done, only to have wasted 2 hours trying to figure out how to get the latest remote commits downloaded onto my local repository, finally giving up, deleting the entire folder, and re-cloning the entire repository. After my Git rant of a few weeks ago, one poster kindly suggested SmartGit/Hg[^] which I downloaded, tried out, and found to be a life saver, and promptly purchased. So yes, that interactive tutorial is absolutely necessary. I still don't fully understand the nuances of branches, commits, stages, stashes, and all the other complexities and bizarre command line syntax nuances that Git forces you to learn -- life was NEVER this complicated with SVN, CVS, or any other version control system I've ever used, going all the way back to RCS in the days of DOS. Happily, SmartGit takes a lot of the pain of Git out of the process. Furthermore, while I understand that people rave about distributed source control, I still do NOT see the point. If you want to share your work with others, you still have to commit to the remote server. I've never in my life needed the complexities of local commits and branches. In my ever so humble opinion, Git solves problems that exist only because Git creates the problem to begin with! Stashes are a great example. I've never in my life needed to use a stash, but stashes exist to solve a problem created by distributed source control, so we have a complex solution because of a "feature." Makes little sense to me. "Cherry picking?" In SVN, that was as easy as right-clicking on a file, reviewing the commits, and picking the version I wanted to extract. Git seems to make simple concepts into demons of complexity. And one final note -- Git's merge, when I had to use it to merge two branches that had evolved over several months, broke a lot of code. In fact, on several occasions, it did some very stupid and inexplicable things, requiring hours of hand comparing to figure out what the merged code should look like (there were probably 50 of these WTF merges to dea
:thumbsup: made me laugh :-) So it's not just beginner's like me who find Git to be shrouded in an impenetrable fog of confusion, as someone said above I'm sure that Linus' support drove the early adoption but for why so many other folk have trudged through the pain of that fog to arrive in a place that is neither worse nor better, just different, I don't know. There must be something other than weight of users that makes Git popular enough to overcome that learning curve, it must be giving folk something they really really need, else Hg would seem to batter Git at every turn and MySpace users would become Facebook users. I doubt I'll ever get through said fog to find out, Hg it is then., smile the contented smile.
-
:thumbsup: made me laugh :-) So it's not just beginner's like me who find Git to be shrouded in an impenetrable fog of confusion, as someone said above I'm sure that Linus' support drove the early adoption but for why so many other folk have trudged through the pain of that fog to arrive in a place that is neither worse nor better, just different, I don't know. There must be something other than weight of users that makes Git popular enough to overcome that learning curve, it must be giving folk something they really really need, else Hg would seem to batter Git at every turn and MySpace users would become Facebook users. I doubt I'll ever get through said fog to find out, Hg it is then., smile the contented smile.
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 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?
If you do not get it then you do not need it. However, people are likely to do what they should not. Some other people see that as a business opportunity, not a nuisance. This is why there are so many "sites offering basic guidance". Is is OK and even advisable to visit that sites for 2 reasons. First, if your circumstances change and you need something like GIT, you will know where to get it. Second, GIT is based on a set of ideas that may be used differently elsewhere and ideas are digested subconsciously as soon as you see them. Unfortunately, many sites offer recipe based advice which is virtually useless.
-
Mike-MadBadger wrote:
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.
Really, the learning curve is just steep at the entry level. Once you are in the club, it gets easier.
Mike-MadBadger wrote:
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.
I have become familiar with about 5 VCS products, and really every one of them has advantages and disadvantages that are somewhat unique. The best one I used was a company-proprietary one which has many features none of the commercial ones have. Git got traction right away because it was designed and written by a popular developer who had a lot of clout in the unix/linux kernel. I'm also not a fan of a UI on a VCS. I prefer doing source authorship in an IDE but source control in a command window.
-- Harvey
H.Brydon wrote:
I prefer doing source authorship in an IDE but source control in a command window.
Nothing wrong with that, but considering the many things that you can do with a VCS but rarely ever use, I'd rather not have to learn every single command that there is, or else have to dig the manual for half an hour just to find out the exact syntax, then go and try in the sandbox to make sure I'm not messing up my working copy. Also, even pro-GIT-users admit that the commands themselves are unintuitive and suffer from inconsistencies. If I absolutely have to use the command line, I'd rather have one that makes sense.
-
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.