Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Git concepts simplified

gitolite.com

Post reply on HN
Print view View original

91–100 of 142 posts

Re: Git concepts simplified

#91

Post by beagle3 »

acqq wrote: post #87

I don't use Git and would like to know how the following problem is solved in Git. Say you have a project which is a hundred megabytes big. And you have to develop almost in parallel three or four "generations" of the project -- let's say. v1, v2 and v3. In parallel means you'd like to be able to build any of the three versions without having to take the version out of the repository first. You can't say that v1 is o…

What does "take version out of the repository first" mean?

You can do a "git checkout" to get a copy out. On a modern drive, checking out a hundred meg history takes a few seconds.

You do not need multiple copies on the disk at the same time - "git checkout v1" when you are working on v2 will do only the changes necessary to make your directory into "v1", and then you can do "git checkout v2" or "git checkout v3" to get another version.

Alternatively, you can just mount your git repo as a filesystem, e.g. https://github.com/davesque/gitfuse (there are other projects - this came up on search, never used it myself).

And anecdotally, my git repos with tens of branches tend to take much less space than one checkout. git is super efficient about storage.

Re: Git concepts simplified

#92

Post by Perseids »

tootie wrote: post #21
angdis wrote: post #10

Earlier 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…

The underlying data structures do matter, even with mercurial. One workflow I immensely appreciate with Git is locally committing some series of messy changesets and commit messages and then afterwards, when I have finished the feature, tidying everything up by rewriting the history (git rebase -i) before I push my commits.

When I tried the same approach with mercurial I found that rewriting the history is not reasonably supported by mercurial. They use these append-only data structures that sound nice, because they assure stability (no already written data is ever in danger because files are only appended) and fit with the general concept of commit->pull->merge. But when you want to change the commit history you clash with the append-only concept. The Histedit extension which is meant to provide this feature has warnings all over the place that what I do is dangerous and might result in data loss with changeset backups written to locations in the working tree. It's horrible compared to Git.

Now don't misunderstand me, Git has a lot of problems UI wise (for example I still don't really grasp what is going on with detached heads). But I find the fundamental design choices more sound than with any other VCS that I have tried.

Re: Git concepts simplified

#93

Post by jlgreco »

guard-of-terra wrote: post #85
jlgreco wrote: post #25

Earlier quoted context omitted.

Linus just created a kernel that can be used with a Unix-like system. The difference here isn't academic, what I am talking about above was created before Linus was born. (mildly interestingly, he apparently missed Unix Epoch by only a few days)

After looking at Git I wonder how Linus could ever constraint himself to POSIX? How come linux system calls don't have ten optional parameters each? Some of them actually mandatory, some changing meaning of the whole call? Why go with boring open, creat, read, write when you can have rerere and prune and annex and reflog?

Not sure what you're getting at here, git developers got to choose their own names for git commands because there was not an existing standard that they were trying to implement.

Do you really think that 'prune' is a worse name than, say, 'fcntl'?

(Also, git-annex is a separate project from git.)

Re: Git concepts simplified

#94

Post by ender7 »

stormbrew wrote: post #84
ranman wrote: post #79

Earlier quoted context omitted.

out of curiosity could you enumerate some of the poor design choices in git?

I'm a huge fan of git (but became one the hard way) and I think that most of the poor design decisions are in the command layer. Largely the tendency for the same command to do several things that, to the user, are wildly different (often because they map to the same fundamental operation on the DAG). As the most simple example, git add both adds a new file to the index and adds changes to an existing file to the ind…

This is exactly what I was getting at. git's command layer is much like the "new" keyword in Javascript -- it's a false abstraction of a relatively elegant underlying system [1]. As it is, the command layer encourages a naive mental model that is both inaccurate and leaky. You end up having to learn both the abstraction layer and the actual system underneath in order to actually understand what any of the commands do.

[1] I assume this was originally done to make git seem more approachable to SVN or CVS users.

Re: Git concepts simplified

#95

Post by Perseids »

guard-of-terra wrote: post #88
wiremine wrote: post #47

Git's learning curve feels similar to the learning curve of a programming language like Python. Once you understand you're not going to pick it all up in an afternoon (just like a language) and that there will be lots more to learn down the road (like a language), git feels great.

Programming language is 80% of my work effort but version control is more like 5%. It should be an utility , I don't want it to be a world of its own right, I don't have needs for insanely powerful version control system because my needs are sane and limited - and that's where git is not so cool.

You can use the same argument about debuggers, dependency managers, editors, etc.

If you are happy with whatever tool you are using, why change?

Re: Git concepts simplified

#96

Post by Perseids »

jlgreco wrote: post #33
damncabbage wrote: post #32

Earlier quoted context omitted.

I agree with the model being great. The git command itself is abominably baroque in its user interface (inconsistencies and strange defaults abound), but I've gotten over that with more effort than I'd like to admit. I love Git's plumbing; I just hate its porcelain.

Eh, I guess I just sort of see hating the porcelain like hating the parens in Lisp.

One of the great reasons to use Haskell instead :D

Re: Git concepts simplified

#97

Post by stormbrew »

ender7 wrote: post #94
stormbrew wrote: post #84

Earlier quoted context omitted.

I'm a huge fan of git (but became one the hard way) and I think that most of the poor design decisions are in the command layer. Largely the tendency for the same command to do several things that, to the user, are wildly different (often because they map to the same fundamental operation on the DAG). As the most simple example, git add both adds a new file to the index and adds changes to an existing file to the ind…

This is exactly what I was getting at. git's command layer is much like the "new" keyword in Javascript -- it's a false abstraction of a relatively elegant underlying system [1]. As it is, the command layer encourages a naive mental model that is both inaccurate and leaky. You end up having to learn both the abstraction layer and the actual system underneath in order to actually understand what any of the commands do…

I find that SVN users have the most trouble with git, so I don't think that's true. Mercurial has a similar underlying model but has a porcelain layer that svn users find far more comfortable.

The branch switching behaviour definitely seems taken from cvs, but somehow works much much better than it ever did in cvs.

Re: Git concepts simplified

#98

Post by EdwardDiego »

beagle3 wrote: post #52
WestCoastJustin wrote: post #20

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

And there's also gitosis, which IIRC is considered superceded by gitolite, but it's still working well for us.

Re: Git concepts simplified

#99

Post by guard-of-terra »

Perseids wrote: post #95
guard-of-terra wrote: post #88

Earlier quoted context omitted.

Programming language is 80% of my work effort but version control is more like 5%. It should be an utility , I don't want it to be a world of its own right, I don't have needs for insanely powerful version control system because my needs are sane and limited - and that's where git is not so cool.

You can use the same argument about debuggers, dependency managers, editors, etc. If you are happy with whatever tool you are using, why change?

Version control is social and there you can see a few maniacs ruining it for the rest of the team.

Debuggers aren't much harder than pour and drink. Dependency managers are pain in the ass (unsolved problem in CS) but you don't wrestle with them every day. I don't use very many features of my Eclipse and I don't use terribly many commands in vim. I also use arrows, I kid you not.

Re: Git concepts simplified

#100

Post by EdwardDiego »

VeejayRampay wrote: post #37
tootie wrote: post #8

There is an inverse relationship the number articles title "x explained simply" and the actual simplicity of x. I honestly don't understand why the developer community refuses to admit the obvious that git is unholy clusterfuck of a product. It has a nice data structure inside it? Name another end-user product for which you are even vaguely aware of what data structures were used.

Word. I have a theory that while git has completely taken over the software industry and most users can "get shit done" with it, very few of them actually understand what the fuck is going on. All those "simple explanations" are really nice theoretical pieces about the merits and design of git itself and most of the time tend to completely ignore (or dodge) the clusterfuck that every day git can be, especially for pe…

> the subtle differences between fetch and pull

While I agree with some of your criticisms, as the resident 'Git guy', I've found no difficulty in explaining to people that pull is a convenience alias for 'fetch followed by merge'.

Post reply on HN