Email or username:

Password:

Forgot your password?
Top-level
arclight

@graydon I'll agree with the latter point - a "how we use git here" guide is essential. I just remember trying to understand git in the late 2000s and how git terminology seemed to intentionally and unnecessarily differ from every other VCS. Docs were sparse and impenetrable and I wound up learning Mercurial instead because it was learnable. I hate that git is conflated with DVCS in general because it is such a niche tool that doesn't translate well outside its niche. We've had commit, branch, and merge forever - why a whole new vocabulary was needed is beyond me. But that's not surprising since I'm not a kernel developer.

2 comments
Graydon

@arclight Something that is free and sufficient tends to win, and git's selling point is that your source control problem is not as challenging as the problems it was created to solve.

The terminology mostly comes in because it isn't doing commit, branch, and merge, it's using a distinct abstraction, and the words for the abstraction weren't there so people just grabbed whatever didn't run away quickly enough. I agree that the result is horrid confusing. (git-scm docs make a heroic effort.)

Graydon

@arclight Which is why the "here are our standard patterns" seems so important; it gives people some place to stand on.

I've had good results from that in the past but it is definitely setup work for the people part of the dev environment.

Go Up