See also Git for Computer Scientists at http://eagain.net/articles/git-for-computer-scientists/
Git concepts simplified
51–60 of 142 posts
Re: Git concepts simplified
#52Gitolite (where this is hosted) is actually pretty cool too. For those who don't know what gitolite is, it is software to works in tandem with git-daemon, that basically allows you to run a centralized git sever with access rules. I created a screencast about it @ http://sysadmincasts.com/episodes/11-internal-git-server-wit...
There's also gitlab, which is a github style app you can run locally. It used to use gitolite internally for access control, but it is now using its own access control system.
Re: Git concepts simplified
#53It's possible, at least after I see the concepts this way, that git has the simple design Hoare was talking about when he said:
“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.” ― C.A.R. Hoare
Re: Git concepts simplified
#54Earlier quoted context omitted.
I think part of the problem is that git, like other version control systems, does not enforce any particular way of working (workflow). When authors try to explain how to use git, they often have a very particular workflow in mind and don't necessarily describe exactly what that workflow is. This can cause major problems when somebody tries to apply advice to their own workflow. I like the graphical approach. It help…
That's not it. Following any reasonable workflow still requires a set of arcane commands and flags that only make the slightest bit of sense if you know how git is implemented. I was able to use SVN successfully without ever knowing a thing about the implementation. I've generally had the same experience with HG and even CVS and VSS back in the day. Git adds sophistication over a prodcut like SVN, but adds vastly mor…
It's that its porcelain is a clusterfuck. The staging area is a hack that greatly convolutes the UI, and it would have been better if it were left out and you just had a way to cherry-pick what you want to commit at commit time (if it wasn't everything).
There's no symmetry in commands. The opposite of "git commit" is "git reset --soft HEAD^", not "git uncommit". "git reset" is three commands in one. I could go on and on.
git was designed as a data model and then a series of slapdash commands that enabled manipulation of that data model. It wasn't designed from the end-user perspective backwards, and this really, really shows.
Re: Git concepts simplified
#55Gitolite (where this is hosted) is actually pretty cool too. For those who don't know what gitolite is, it is software to works in tandem with git-daemon, that basically allows you to run a centralized git sever with access rules. I created a screencast about it @ http://sysadmincasts.com/episodes/11-internal-git-server-wit...
There's also gitlab, which is a github style app you can run locally. It used to use gitolite internally for access control, but it is now using its own access control system.
I've used both. Gitolite does everything on the command-line, including access management.
Gitlab is essentially an open-source clone of Github's web UI. Of the two projects, I think Gitlab is harder to deploy and far more resource-intensive on the server, but easier for users.
Re: Git concepts simplified
#56I prefer the Fox News tutorial on the subject. 'Repo' means 'reciprocity' or 'reposotory' if you didn't know.
http://static4.businessinsider.com/image/52330e4deab8eaef7ac...
I also wanted to post this screenshot and then saw your comments...
Re: Git concepts simplified
#57... that is not simple. But I'm figuring it out anyways. I commit my changes to my own repo and keep building changes under HEAD, committing as I go. If I get a branch from a buddy and I want to add it to my code, I either merge or rebase depending how I want his commits to be intertwingled. Because GIT is decentralized, there's no difference between merging in a buddy's branch, and import the latest changes from Ori…
> The decision of when to merge vs. rebase is still confusing to me.
i always thought it was "never rebase commits you have pushed" at least you know about rebase though. :)
Re: Git concepts simplified
#58Earlier quoted context omitted.
I don't get this attitude. The DAG is exceedingly simple and I think can be taught reasonably in only a few minutes. From there you really only need to teach a very minor amount of the UI, and teach the user how to perform "I want to do this to the DAG" => "This is what I type" translations on their own. I've seen all of this done well in sub-hour presentations. Mercurial on the other hand has a pain in the ass datam…
Git is simpler than any other VCS, but VCS itself is not simple concept to understand. That's what he's saying, and I agree. I use git all the time, but it's not easy to understand the whole version control thing as a beginner. Also Git is not just about DAG, you need to be able to understand the decentralized nature, etc. In that sense, some people may find SVN easier to understand.
Exactly what I meant. If you're working with people who need to learn what a DAG is in the first place, that adds some overhead. After that you still need to understand that your working directory is just a scratchpad, and branches aren't actually like real-life tree branches but instead they're pointers to the ends of those real-life branches, etc. Not exactly simple.
Conceptually speaking, a centralized VCS -- one where you check out files, make changes, and check files back in when you're done -- is vastly simpler than Git. Sure, it's also much less powerful (and I would choose Git a million times over such a system), but it's definitely simpler.
Re: Git concepts simplified
#59... that is not simple. But I'm figuring it out anyways. I commit my changes to my own repo and keep building changes under HEAD, committing as I go. If I get a branch from a buddy and I want to add it to my code, I either merge or rebase depending how I want his commits to be intertwingled. Because GIT is decentralized, there's no difference between merging in a buddy's branch, and import the latest changes from Ori…
One small point: on check-in, I don't think it's exactly that origin is also rebasing/merging just like you did. It's more like origin is just taking whatever you have and copying it exactly. The merging/rebasing process itself only happens locally.
Regarding merge vs. rebase, here's my approach: rebase to keep history a straight line when it's just your changes and it's just a few commits. If it's too many commits you tend to have more conflicts and it's usually easier to merge.
Re: Git concepts simplified
#60Earlier quoted context omitted.
That's not it. Following any reasonable workflow still requires a set of arcane commands and flags that only make the slightest bit of sense if you know how git is implemented. I was able to use SVN successfully without ever knowing a thing about the implementation. I've generally had the same experience with HG and even CVS and VSS back in the day. Git adds sophistication over a prodcut like SVN, but adds vastly mor…
It's that its porcelain is a clusterfuck. The staging area is a hack that greatly convolutes the UI, and it would have been better if it were left out and you just had a way to cherry-pick what you want to commit at commit time (if it wasn't everything). There's no symmetry in commands. The opposite of "git commit" is "git reset --soft HEAD^", not "git uncommit". "git reset" is three commands in one. I could go on an…
I might not [EDIT: in fact, was not: see reply below] be appreciating the way that the staging area convolutes the UI for you, but you can pretend it doesn't exist by always just doing commit -a. And, if you want to "cherry-pick what you want to commit at commit time", well, that's what the staging area is for, isn't it?