Hi Kramer, I know what you mean. I'm also an experienced, IT professional and findi Git to be very difficult and confusing to use. According the Linus Torvalds it used to be a much worse. He said it used to require quite a lot of brain power, but that other came along after him and make it "cool for mere mortals" to use.
But still, I also feel the cognitive burden is still too high, especially if they expect people to use it for art assets and text files. The creators point out that it can be used for any kinds of files, not just source code, but as with Linux itself, I think they are deeply out of touch with the typical computer user if they think this is ready for your average consumer. If you think its difficult enough for one person to master, try leading a team of 8 otherwise competent developers to all get their head around Git at the same time! So if it makes you feel any better, you're no alone. Also, I'm sorry that users here like Konstantin can be so abhorrently unpleasant. While he is very knowledgable about Git and can be very helpful on technical matters, apparently that technical knowledge was gained at the expense of some more soft, social skills. He once told me that I "sound like a "religious zealot" for simply suggesting a Git GUI, like SmartGit, could save time, compared to command-line operation. I think this mentality of arrogance and condescension in the Git community, and Linux community in general, comes from the top. As others have pointed out, Linus Torvalds has a famously odious personality: http://me.selah.ca/dear-linus-torvalds/ Its really is painful to watch him in action http://www.youtube.com/watch?v=4XpnKHJAok8 Unfortunately some of this fans it seems end up adopted many of his worse character traits. So on to more practical matters, how many people are on your team? Is everyone new to Git or are there already some highly-competent users? Can you simply schedule time with the other team mates so they can bring you up to speed? If whole team is struggling with Git, perhaps you can make a case for another product. Or maybe you can convince your manager to invest in some third-party training? Here's one Git consulting group I dug up. There are others you can find with a little searching: http://gitimmersion.com/ In my case, I find the complex issue isn't with Git itself, but its a side-effect of using Git. Konstantin suggests we document our criticisms "with clear use-cases where you can demonstrate what you do, what you get, why you think what you get is wrong and how do you think Git should behave instead" But the issues I struggle with are not necessarily because I think Git behaved badly but because allowing multiple developers to make indiscriminate changes across multiple files in their efforts to address issues and add features becomes a huge cluster-fuck to integrate into a release. Git has clear strengths over a product like MS SourceSafe in its ability to support distributed access, but some of these features are a mixed blessing. SourceSafe has a locking model which prevents users from editing the same file. This can be very annoying, as when someone forgets to check-in their work before going to lunch, or going home for the weekend. (Also SourceSafe discourages the creation of branches, because creating a new branch for a large project is a very expensive operation.) Git "solves" these limitations by permitting a very flexible, distributed model where many developers can all generate many versions of source code, but this activity can generate a lot of complexity when it comes time to integrate all those difficult, and possibly incompatible, revisions. So its nice when I can edit an HTML file and modify the header, while another users edits the same file and modifies the footer. Then while merging we can see there is a merge conflict and easily integrate each of our respective edits into a new file. But it can be a nightmare when you have to try and figure out which edits to keep when trying to merge together multiple files from multiple branches with overlapping changes to source code and CSS. At least that's what I struggle with. So for me it's not simply a matter of making constructive criticism so someone can fix a bug in Git; it's more a matter of dealing with the side-effect complexity that Git generates. Or maybe we are just not using it right or something. Regardless, it may be powerful and flexible, but its probably the most confusing and frustrating software application I've had to deal with as well. On Tue, Oct 30, 2012 at 7:31 AM, kramer.newsreader < kramer.newsrea...@gmail.com> wrote: > I am a fairly experienced developer and I have never had issues working > with source control tools before git. > > I take a new job. I am working with git. I am thinking about quitting > over having to use it. > > Every source control tool I have used before has an easy command that > says: "Use these changes right here. Yes there are conflicts, but these > are correct." > > How can I get to "Not currently on any branch" when I was on a branch and > didn't ask to switch branches? > > Where is that with git? > > Why is the git information model SO COMPLICATED? > > Why can't there be a way to > > Why is the documentation so inadequate? > > Why do I have to be a source control engineer just to be a software > developer? > > -- > You received this message because you are subscribed to the Google Groups > "Git for human beings" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/git-users/-/2e2Mu1N2tVYJ. > To post to this group, send email to firstname.lastname@example.org. > To unsubscribe from this group, send email to > git-users+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/git-users?hl=en. > -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To post to this group, send email to email@example.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.