Why do I have to be a source control engineer just to be a software developer?

[kramer.newsreader]

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?

[Konstantin Khomoutov]

On Mon, Oct 29, 2012 at 03:31:13PM -0700, kramer.newsreader wrote:

> I am a fairly experienced developer and I have never had issues working
> with source control tools before git.

[...]

> Why do I have to be a source control engineer just to be a software
> developer?

Every time I see a post like this I always wonder what did the author
really intend to achieve by writing it?

But this is a rather rhetorical question.
The real question is: why did you post this to a technical support
mailing list rather than blogging, tweeting or whatever
buzzword-of-the-day'ing it?

You definitely has the right to express your opinions, vent and so on
but please refrain from polluting the *techincal mailing list* with
such non-constructive whining in the future, thanks.

As to the bits of sense in your post... you basically have these
possibilities:
1) Educate yourself. Git is not the easiest tool out there but clearly
there are gazillions of those who use it routinely without apparent
problems and quite many of them actually enjoy using it.
I could now go on to explaining why I think there are things about
Git which compensate for that complexity, but your rant is clearly
provocative, so I'll refrain. No holy wars here.
2) I understand there are different mindsets and different preferences,
so it's okay if Git is not for you or you're not for Git. No
problem, really. For instance, I'm following the Fossil mailing list
and from time to time one newborn Git refugee or another posts
about their happy departure from that horrible SCM. Being a Fossil
user as well as Git's, I always grin at those stories but I see what
merits of SCMs those people value most and understand they just
don't match mine. So those people have their point, but so do I.
So why be a Git martyr? Advocate using another tool to your
colleagues, to your boss or to whoever is in charge for the selection
of tools.
3) Quit this job. This is not a snide remark. This situation is not
really different from, say, being forced to program in C++ -- some
people hate it, some people praise it.

And last but not least: if you have any *constructive* (please re-read
this word several times until it sinks in) 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, please direct them to the main Git list instead, which is
git at vger.kernel.org. We here have really nothing to do with
someone's ideas about what's wrong with Git as this is merely a support
channel for newbies.
If you think I'm making fun of you directing you to the main Git list,
please don't -- just dig up its archives, and you'll see that features
get updated, implemented and fixed, and documentation improved in
response to constructive complaints.

[Alexandru Pătrănescu]

Git is very different than other VCS (like SVN or whatever you used before). I suggest reading the Pro Git book with a clear mind, open to new ideas, not linking what you read with what you know that command did in other VCS.

Git is really not that complicated, as his creator described it, it is a stupid content tracker. Please prove yourself smart, and show us that you are worth of the "software developer" attribute.

I'll answer you only the last question:

If you will learn how to use git, you will be a better software developer. Even if Git is mainly an VCS, it can do more than that, changing the way you develop software, letting you do stuff you wouldn't think is possible.

The rest of the questions you will answer yourself in time...

[Charles Manning]

Ok, I like git now that I can more or less function, but I agree with
the original poster.... git is a huge learning curve even with reading
a heap of books and reading all the tutorials.

git could really use some training wheels to make it easier to get going.

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

[Max Hodges]

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.

--
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.

[Thomas Ferris Nicolaisen]

On Monday, October 29, 2012 11:31:13 PM UTC+1, kramer.newsreader 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.

I'm afraid your employer has done a poor job here. If they weren't interested in giving you the necessary training for the job, they could at least have configured and set things up for you, with a couple of git commands to get things done. This is fully possible, and you should give this feedback to them (and if they don't listen to feedback like that, you probably should quit anyway).

 

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."

Yeah, SVN has about a handful of commands you need for day-to-day work. For Git you need 5 just to get started, then another 5 when it comes to collaborating with others, and then another 5 for good measure. 

The reason for this is Git's feature-richness. I like to say Git is not complex, it is simple multiplied by 20. At its core, it's just a graph with three kinds of objects, and all those commands operate on this elegant data structure. However, that's something you start to realize after using Git for several months. 

 

How can I get to "Not currently on any branch" when I was on a branch and didn't ask to switch branches?

There are several modes in Git that can detach you from a branch to go travelling down history, for good reasons:

* git checkout <commit, or tag>, will check out code as it was at some point (not necessarily a branch)

* git bisect, will go through history scanning for the introduction of a bug

* git rebase, will rewrite history, and can leave you in an in-between state where you have to resolve conflicts

Not sure which one it was, maybe it was a git pull --rebase? Please provide us with your history and we might be able to explain.

 

Where is that with git?

It will all make sense at some point :)

 

Why is the git information model SO COMPLICATED?

The model isn't so complicated. The problem is that there are so many features, and you haven't used these features before (even when you think they are the equivalent of something in SVN/CVS/whatever, they probably are not).

 

Why can't there be a way to

Usually, there's a way to do everything in Git :)

 

Why is the documentation so inadequate?

Now this one ain't right. There are loooads of documentation. I personally like the git-scm.com/pro-git book, a great introduction: http://git-scm.com/book

Here's another easy guide for just getting started in Git: http://rogerdudler.github.com/git-guide/ (more links at the bottom of the guide)

And here's another more extensive guide: http://think-like-a-git.net/

 

There are also a handful of books you can buy, and a gazillion more guides and articles on the internet. Plus an answer for every question you could ever think of on stackoverflow.com.

If you don't know where to start, a good place is here on this mailing list.

Why do I have to be a source control engineer just to be a software developer?

You don't have to. Either, your company's source control engineer (who should be a Git guru) should set you up so you don't have to think so much about these things. 

If you have to learn it by yourself anyhow, there might be some relief in knowing that there is no other source-control system people will fall so much in love with after learning it :)

[Tim Chase]

On 10/29/12 17:31, kramer.newsreader 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.

I'll admit that I too took about 4 or 5 goes at learning git before
it finally sunk in and I found I could do things natively with git
that were either impossible or at least quite difficult in other VCS
tools.

Others have addressed most of your questions, but I didn't see this
one get answered yet:

> 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."

You have to intercept these at the point of the conflict. Usually a
merge or pull. You can use the "strategy" option to say "mine,
dagnabbit!"

$ git merge --no-commit -s ours some_other_branch
# survey the merge results
$ git commit -m "Merged in some_other_branch"

I don't know which other "every source control tool" you're talking
about, as I don't recall seeing (and thus haven't used) such in any
of the VCSes I've used (git, svn, hg, bzr, or «shudder» Source Safe).

That said, I almost *never* want the "ours" strategy. If there are
conflicts, I want to review them and make an informed choice about
the result.

> Why do I have to be a source control engineer just to be a software
> developer?

You can get by with just a handful of commands for basic activities.
Most of my work involves just the following: init/clone, status,
log, commit, add, push, fetch/pull. Once you have these, you can
replicate what most of my [current & past] coworkers have used
source-control for.

When you get to more advanced requirements (branching/merging,
editing history, partial commits, multiple remotes, etc), git is
there for you. Branching/merging adds another two commands
(unsurprisingly, "branch" and "merge", though I suppose
"cherry-pick" might also be used here). Editing history adds
"rebase" for most of what I do. So you start off with 7-9 basic
commands, then add/learn more as your requirements grow.

-tkc