The Lounge is rated PG. If you're about to post something you wouldn't want your
kid sister to read then don't post it. No flame wars, no abusive conduct, no programming
questions and please don't post ads.
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!
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.
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.
Really, the learning curve is just steep at the entry level. Once you are in the club, it gets easier.
I've always imagined that would be true but unfortunately I don't use any of them enough to get that familiar, so I am biased to something that's easy to use for the basics (Hg) and has a UI (TortoiseHg) so I don't have to remember command line instructions and switches I haven't used in several days / weeks.
Advantages / Disadvantages - Absolutely, but if your needs are very simple you don't notice the advantages when something you need is a disadvantage (learning curve like the Eiger).
So maybe I should change the title ...And that's the problem with Git for Basic Users / Noobs / Beginners. Perhaps we're not their target audience.
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.
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 deal with.)
And for the Git lovers out there, apologies for being harsh and possibly speaking with my head up my arse. Git, until I was pointed to SmartGit, was constantly getting in the way of my working productively, and therefore it takes a lot of heat. Now that I'm using SmartGit, I now have a series of simple steps that I perform to commit my stuff and to check it out on my other computer. Why it should be any more complicated than that is beyond me. 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.
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. But then what works for one person may not work for another - you may find the simplicity refreshing, and it may not bother you that it lacks features if you never use those features anyway.
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.
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.)
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.
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.
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.
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.
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[^] 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.
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.
Mr A :"What will happen if there is a exception inside a lock block ?"
Me : "How are you handling the exception...i mean try...catch and finally ??"
Mr A: "I am not handling it at all."
Me " "Now you have much bigger things to worry about then deadlock "
and this was the last question...i said i am done with the interview.
It sounds a heck of a lot like an interview I had a while back.
The first thing the interviewer (22 year old - in the field for 12 months) told me was that he had tried to hack/pen test my site ... that made be laugh in a way - but in the back of my mind I was thinking something darker...
Anyways - this position was for web apps - so I asked him what types of server infrastructure they had - and he told me he did not know?!? How can you write web apps without knowing what type of server and environment you are dealing with in the first place is beyond me...
Into the interview, I got asked - ok - write a function (on paper) that will accept an integer and ensure that the int had not been passed in before. (C#)
So, first I write it using a class with generic list of ints and using the .contains(newInt) type thing.
He said no, that's no good.
So, then, I proceeded to do it 2 other ways.
Finally he said - that's wrong - and the correct way was to use a hashtable and catch the error when the collision occurred.
Now, if you know what is going on under the hood with SEH and stack frames when using try / catch - and the overhead of a hashtable ... (referring to what C does with SEH under the hood) - I had to scratch my head.
So - I proceeded to explain what was going on under the hood, and this little know it all was put aside and it was downhill from there. Last I heard, his team brought the company to its knees for 3 days for some weird coding they were doing. (public facing SOA).
seriously I do not understand this kind of interview and specially when they ask question like this. Even I have taken many interview and only thing I look into a candidate is how good is his logic Give him some puzzle to solve or ask him to design(no coding just a overview) a solution for a problem.
I hate it when I get question like what is events or delegates or generics and I always give the same answer.. Sorry I do not know the definition all I can tell you is how, where and when to use them if that is good enough for you.
Considering Exceptions are expensive to throw vs. the cost of a lookup, they should only be used to catch, well, exceptional cases. They should never be used as a dependancy in the normal course of an algorithm."
Then I get up and thank him for his time, the opportunity, and decline the position and dance my way out the door as fast as possible.
I live in Waterloo - so you have a lot of kids coming out of university thinking they know it all and the world owes them everything..... they haven't lived through bringing a bunch of servers back up from hell yet.... they probably think that wireshark is a roach clip.
First thing I learned when helping out with technical interviews was to listen to what people are saying. You never know their method may not be the way I do it, but could offer another way of accomplishing the same task. Or maybe applied to another task…If you are not in constant learning mode then you’re probably doing it wrong (Okay I have worked with some people that I never agreed with, but they would spend weeks trying to figure out the simplest of tasks, you can only imagine the garbage they wrote).
Common sense is admitting there is cause and effect and that you can exert some control over what you understand.