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

71–80 of 142 posts

Re: Git concepts simplified

#71

Post by sethrin »

Pxtl wrote: post #63
dcre wrote: post #59

Earlier quoted context omitted.

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

> 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. But then what happens when I merge/rebase locally and publish at the same time as somebody else? I assume the origin doesn't keep a lock on the whole mess while I'm doi…

Are you using gitflow? https://github.com/nvie/gitflow

So yes, if you try to push without pulling down changes, then you will get an error about the histories having diverged. Sometimes you don't care about wiping out history, and can just push with the -f parameter, but most of the time that's your cue to rebase.

Branches are cheap in git, and there's no real advantage to doing dev work in the master branch. You should create a branch at least as often as you develop a new feature. In git, history isn't necessarily a static thing. Sometimes you need to mangle it to achieve your goals, and sometimes you fat-finger the merge and do time in History Hell. In either case it's only a huge flaming deal if you're working on master. Ditto with the problem you describe.

I recommend the O'Reilly book on Git. The simple explanations are nice in theory, but this is a complicated subject and deserves a full explanation. There are very sound reasons for the how and why of git, and they should be within the grasp of any aspiring programmer.

Re: Git concepts simplified

#72

Post by anandabits »

This is very nice as a review of Git, but probably best in that context rather than an initial presentation of the concepts. I really enjoyed the Source Control Made Easy series by Jim Weirich. It presents the same information in an easily digestible, step-by-step approach. Highly recommended for those trying to understand how Git works and how to best make use of it.

http://pragprog.com/screencasts/v-jwsceasy/source-control-ma...

Re: Git concepts simplified

#73

Post by tootie »

jlgreco wrote: post #68
tootie wrote: post #65

Earlier quoted context omitted.

People who refuse to see the ugliness in git are the same people who think it's manly to live on the command line. Using git through Eclipse looks a lot like using SVN through Eclipse. If I right-click on a file and go Team > Replace With > Remote and select 'origin master' is saves me from trying to remember the obscure list of flags I need to pass to the command line to do the same thing.

Refuse to see the ugliness? No, I really don't see it. Sure, a few flags could be cleaned up, but the beauty of the rest of git more than offsets a few weirdly named flags. Meanwhile git through eclipse causes nothing but trouble as far as I have seen. Making it seem like SVN is exactly the problem, git isn't like SVN so if it seems that way, something is going wrong. Pretending git is something that it isn't will bi…

The fact that I can select files to add/commit with checkboxes and permanently check a box that will push every commit is exactly what I want 99% of the time. I know that isn't the "git way", but the "git way" has no value for the kind of projects I work on.

Re: Git concepts simplified

#74

Post by Pxtl »

sethrin wrote: post #71
Pxtl wrote: post #63

Earlier quoted context omitted.

> 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. But then what happens when I merge/rebase locally and publish at the same time as somebody else? I assume the origin doesn't keep a lock on the whole mess while I'm doi…

Are you using gitflow? https://github.com/nvie/gitflow So yes, if you try to push without pulling down changes, then you will get an error about the histories having diverged. Sometimes you don't care about wiping out history, and can just push with the -f parameter, but most of the time that's your cue to rebase. Branches are cheap in git, and there's no real advantage to doing dev work in the master branch. You sho…

I'm not using git at all, I'm trying to understand how it works before I start. Every guide to git I read before was a completely opaque mess of terminology, so this is the first time it's starting to make a lick of sense.

Re: Git concepts simplified

#75

Post by stephengillie »

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.

After reading the post (and many others), I think I'm starting to get it:

-You have a directory/folder (data store) where all of the files are stored

-Some files (blobs) are data files

-Some files (trees) are hierarchy - they specify the structure of the data (blob) files, and how they connect to each other (like a database)

-Some files (commits) are snapshots (think VM snapshot) of the arrangement of the blobs on the trees (data file structure)

-Some files (tags) hold metadata about the data files (blobs)

And it's all tied together by SHAs (GUIDs) which are just a random number that's so huge it's probably unique.

You can use URLs to point to any of these files, so you can tie together files from different locations at once.

Re: Git concepts simplified

#76

Post by develop7 »

th3dude wrote: post #16
develop7 wrote: post #15

Earlier quoted context omitted.

> Google stuff as you go. Are you implying git man pages are useless to newcomer?

Useless? No. Overwhelming at times? Absolutely. I think that Google is probably the best way to go, because not only will you get the man pages as high ranking hits, but you'll also get great hits from sites like StackOverflow and blogs that can explain things better.

> Overwhelming at times? Absolutely.

"At times"? Well, maybe, if you have plenty of time, no paid work to do and no deadline approaching.

Re: Git concepts simplified

#77

Post by jlgreco »

davvolun wrote: post #69
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.

That argument doesn't really make sense. If x were fundamentally simple, why would I need a simple explanation for it? Clearly git is, or can be, complex, and a simple, simpler or simplified explication would be helpful. None of that implies that "git is [an] unholy clusterfuck of a product," it means that git is complicated. For 99% of the work you do with git, it isn't even that complicated and you don't need to be…

It is simple because a simple explanation is possible. Simple doesn't mean "intuitive to proverbial grandmother".

Git is clever, moderately novel and therefore unfamiliar (depending on your background), and simple. There are not many concepts present, and the concepts that are there are not difficult to understand, but those concepts need brief introduction because they are concepts that many will be unfamiliar with.

If you buy a checkers board it will come with a (very simple) rulebook. You aren't born with some sort of natural checkers ability, you have to learn it. Nobody would claim that checkers isn't simple though.

Re: Git concepts simplified

#78

Post by jlgreco »

tootie wrote: post #73
jlgreco wrote: post #68

Earlier quoted context omitted.

Refuse to see the ugliness? No, I really don't see it. Sure, a few flags could be cleaned up, but the beauty of the rest of git more than offsets a few weirdly named flags. Meanwhile git through eclipse causes nothing but trouble as far as I have seen. Making it seem like SVN is exactly the problem, git isn't like SVN so if it seems that way, something is going wrong. Pretending git is something that it isn't will bi…

The fact that I can select files to add/commit with checkboxes and permanently check a box that will push every commit is exactly what I want 99% of the time. I know that isn't the "git way", but the "git way" has no value for the kind of projects I work on.

The "git way" is just whatever way you want. If you want a central server that you always push to, that is fine; there is no problem with that.

The problem is with that particular tooling. That tooling presents a workflow that is perfectly fine (though it is problematic that it does not facilitate alternative workflows, which becomes particularly problematic when working on a team with other users), but it obscures what is actually going on and executes that workflow imperfectly, generally falling over in rather novel ways. When it fucks something up, and it eventually will, you will need an understanding of the basic concepts underlying git to figure out what went wrong. I'm not saying you need to know how to use the default git porcelain, I'm saying you need to be aware of the concepts underlying git.

Re: Git concepts simplified

#79

Post by ranman »

ender7 wrote: post #66
stormbrew wrote: post #44

A suggestion for anyone hoping to write accessible tutorials: > Hg folks should read this section carefully. Among various crazy notions Hg has is one that encodes the branch name within the commit object in some way. Unfortunately, Hg's vaunted "ease of use" (a.k.a "we support Windows better than git", which in an ideal world would be a negative, but in this world sadly it is not) has caused enormous takeup, and doz…

There's also a bit of "people in glass houses..." to this comment. I don't think git really wants to start a fight when it comes to poor design decisions.

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

Re: Git concepts simplified

#80

Post by hibbelig »

DougWebb wrote: post #35
tootie wrote: post #21

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

I'm curious: did you use branches and labels in SVN? I've come across many svn repositories that don't use the trunk/branches/tags layout, and as a result the developers keep completely separate repositories for slightly different versions of their projects instead of creating branches. I've even seen new repositories created for each release version of the project. If you're using svn you need to understand the impl…

Well, I know _that_ copies are cheap in svn, but I have no idea _why_. Yet I hope that I grok branches and tags.
Post reply on HN