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

31–40 of 142 posts

Re: Git concepts simplified

#31

Post by jlgreco »

pjmlp wrote: post #26
jlgreco wrote: post #12

Earlier quoted context omitted.

> Name another end-user product for which you are even vaguely aware of what data structures were used. Unix. You are operating primarily on a tree of files and streams of text. To operate on these you have a wide array of utilities that perform simple tasks (and a handful that perform complex tasks as well) that, when composed, allow you to perform any transformation you want. You can get a freshman CS student off t…

Except there isn't a single version of UNIX, each flavour has its own deviations.

Technically there isn't a single version of Git either, though (thankfully) they can all operate on the same repositories (whereas in UNIX land, you'll find different file systems that the others do not support). They do however have some different capabilities. jGit for instance can push to S3, which is pretty neat.

Re: Git concepts simplified

#32

Post by damncabbage »

jlgreco wrote: post #11
dcre wrote: post #2

I love Git, but I'm pretty sure there's no way to explain it simply.

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…

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.

Re: Git concepts simplified

#33

Post by jlgreco »

damncabbage wrote: post #32
jlgreco wrote: post #11

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

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.

Re: Git concepts simplified

#34

Post by recursive »

dsego wrote: post #9
recursive wrote: post #6

Earlier quoted context omitted.

I thought I would try that, but I'm probably still not really thinking in Git. I never branch or merge for example, since I never think of doing that. I understand this isn't really normal git usage.

Me neither. But I think I should. Every time I want to try something new, take a new direction in code or add a new feature I should branch, so I can safely add or remove pieces of code. Things not related to that new feature, like bug-fixes, should be done in the main branch and then get pulled into the feature branch. I'm just too messy with my commits to do that, because it requires making frequent smaller commits…

I am familiar with that approach, but it's really not how I work. If I'm not done with a feature, I don't check in. And I've never needed to work on two features at the same time.

Re: Git concepts simplified

#35

Post by DougWebb »

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…

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 implementation to get why copies are cheap, so that you can understand how to use branching and tagging appropriately.

Re: Git concepts simplified

#36

Post by Pxtl »

... 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 Origin into my branch. So I fetch the changes from origin/master and then rebase or merge my repo on top of that. That's my "Get Latest" command, basically, right? Assuming I'm working on "master", I fetch then rebase or merge origin/master.

To check in, I tell the origin server to take my stuff and then rebase or merge its master with that.

I still feel like this is a rather baroque approach to the problem... managing oodles of local commits separate from rebase/merges seems bizarre, above and beyond the decentralized approach that makes my own repo, my peer, and the "origin's" stuff all equivalent.

The decision of when to merge vs. rebase is still confusing to me.

Re: Git concepts simplified

#37

Post by VeejayRampay »

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 people starting up with it.

I'm talking about the botched merges, the hour-long rebases with 156 git rebase --skip, the "your branches have diverged" mysteries, the subtle differences between fetch and pull, the fact that all the GUI I've seen so far, far from being a tool, are actually complicating the task with their own little syntax.

If the underlying data structure is so beautiful, then how come there's no UI where I can simply drag branches around, have an actual "OOPS, MISTAKE, LET ME UNDO" button, reorder my commits with the mouse, something that holds my hand and actually cares about ALL git users, not the 1% connoisseur elite?

Don't get me wrong, I have zero doubt that git is in fact an absolutely great tool with a very intelligent design and that the users are to blame for not understanding it, I'm just thinking that if after more than 5 years of git-as-a-dominant-dvcs I keep seeing the same puzzled faces looking at a series of SHA-1 like it's the answer to the universe over and over again, there's something that's not quite right.

That being said, this is indeed one of the most comprehensive articles I've ever read about git.

Re: Git concepts simplified

#38

Post by Pxtl »

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…

The problem is that with SVN, you can get in gradually. To start, the branchless approach still gets you a great service - obviously an incomplete one, but better than not having source control at all. And you can have leaders who are the only people who have to think about branching and merging and have people very gradually move into that role.

Git seems to force you to dive straight into the deep-end, since everything is a branch, even your own local working folder.

Re: Git concepts simplified

#39

Post by jeltz »

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…

I used SVN for years without understanding it and that caused me to get weird merge errors I never managed to figure out. Git on the other hand I understood after a few weeks of using it.

Since I failed to understand SVN after years of use I would say it is more complex.

Re: Git concepts simplified

#40

Post by jeltz »

jlgreco wrote: post #11
dcre wrote: post #2

I love Git, but I'm pretty sure there's no way to explain it simply.

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…

As soon as you understand that git is just a DAG then it becomes simpler to understand and reason about than any other VCS I have used.
Post reply on HN