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 <
[email protected]> 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 [email protected].
> To unsubscribe from this group, send email to
> [email protected].
> 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 protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/git-users?hl=en.

Reply via email to