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

Git Is Simpler Than You Think

nfarina.com

Post reply on HN
Print view View original

21–30 of 122 posts

Re: Git Is Simpler Than You Think

#21

Post by gks »

psychotik wrote: post #16

I wish the author would've explained the motivation to move from SVN to Git, other than 'it was winning over the web'. Was SVN just not working for them, for some reason? Are there things that he and him company wanted to do that wasn't possible with SVN, but was with Git?

Quite frankly there's no more reason for "why we moved from SVN to Git" topics anymore. It's been beat to death.

Better to keep up while the team is small than to try to move even more people over later and turn into mega-corp still using CVS.

Learning something new isn't necessarily a bad thing. I question people that are unable to try to learn something new every day. It takes a few minutes of your time and you can learn something. Sure, git might take more than a few minutes… but why not TRY?

As for requesting why they switched from subversion to git… yea, as I said, you have a billion articles written out there by now about WHY. There aren't more needed. The benefits are pretty clear if you read any one of those other articles.

Of course, this more leads into "why git and not mercurial (or any other DVCS)?" Which again, has a billion other articles written up on it.

Re: Git Is Simpler Than You Think

#23

Post by chriseidhof »

(a bit off-topic)

Oh no! I now see cognitive dissonance everywhere. I realized that it's the same with git: maybe we like it so much because it took such a hard time to master. I still don't feel like I master it. However, reading some books on git and understanding the philosophy did make it feel simpler.

Re: Git Is Simpler Than You Think

#24

Post by Lewisham »

I would have really liked it if the author had mentioned exactly how the co-worker in the beginning had got into the "3-way merge" state, and some how got onto a non-existent branch. I don't know what it means, and I've never got there, so I'd love to know how it happened.

(or maybe the author did mention it and I missed it?)

Re: Git Is Simpler Than You Think

#25

Post by schleyfox »

masnick wrote: post #3

Thanks -- great article. This is the most readable and straight-forward explanation of git's internals that I've seen (and I've read a bunch of articles/books/etc. looking for resources to help others learn git). I'd also recommend The Git Parable ( http://tom.preston-werner.com/2009/05/19/the-git-parable.htm... ) for anyone who hasn't read it. Different focus, but also helpful for understanding git's philosophy.

I found git to make a lot more sense personally after reading http://eagain.net/articles/git-for-computer-scientists/ . The git parable is also very good.

Re: Git Is Simpler Than You Think

#26

Post by ekidd »

If you don't understand git, then don't mess around with 'rebase', 'push -f', or any other command that tries to edit history. These commands assume that you have a strong mental model of how git works, and this is how the author of the article got into trouble.

It's possible to build a very successful git workflow using only the following commands:

    git clone git:...
    git add path/to/new_file
    git commit -a
    git pull
    git push
(Yes, commit before pulling, rather than vice versa.)

If you want to use branches, you need to add:

    # Showing branches.
    git branch -a
    gitk --all

    # Checking out branches.
    git checkout some_branch

    # Creating and pushing a new branch.
    git checkout -b new_branch_name
    git push -u origin new_branch_name

    # Checking out an existing branch.    
    git checkout -b some_branch origin/some_branch

    # Merging a branch into your current branch.
    git pull origin some_branch
This workflow is extremely safe. At worst, you might need to resolve a merge conflict.

But if you start digging around under the hood, and you start editing your commit history, you'd better be prepared to understand what you're trying to do.

Re: Git Is Simpler Than You Think

#27

Post by eslaught »

Lewisham wrote: post #24

I would have really liked it if the author had mentioned exactly how the co-worker in the beginning had got into the "3-way merge" state, and some how got onto a non-existent branch. I don't know what it means, and I've never got there, so I'd love to know how it happened. (or maybe the author did mention it and I missed it?)

It's the result of a merge conflict (e.g. after attempting a rebase). If you work regularly with other people you end up seeing this a lot (or rather, whenever you both edit the part of the same file at the same time).

Re: Git Is Simpler Than You Think

#28

Post by nicky0 »

ekidd wrote: post #26

If you don't understand git, then don't mess around with 'rebase', 'push -f', or any other command that tries to edit history. These commands assume that you have a strong mental model of how git works, and this is how the author of the article got into trouble. It's possible to build a very successful git workflow using only the following commands: git clone git:... git add path/to/new_file git commit -a git pull gi…

Why the -u on push?

Re: Git Is Simpler Than You Think

#29

Post by masklinn »

masnick wrote: post #6
wccrawford wrote: post #2

No, actually, it's not. And that post proves it. You can do some things to make it easier on yourself (and others) but it's not simple. You find out how un-simple it is when you hit one of those magical corner cases. Don't get me wrong, I love Git. I far prefer it over SVN and CVS. But it's not simple.

I think the author's point is that the git internals (i.e. the .git folder) are simple; I don't think the author is disputing that the commands sitting on top of the git internals are sometimes horribly complicated. The fact that the contents of the .git folder can be explained in ~2000 words (10 min of reading) is impressive--this would be impossible with a more complicated data model. FWIW, compare: http://www.goog…

> All the results for the svn search are about getting rid of these folders -- nothing explaining their contents.

That would be because there's little to no content in the svn folders, and none of it is user-consumable: all the metadata manipulation is done via svn's properties[0] and their cli interface (proplist, propset, propget and propdel).

Apart from these, the content of the .svn folders (at least before 1.5) is pretty much only duplicates of your checked-out files. All the brains live in the (remote) repository, not in the .svn folders. I've never seen any case where somebody would go muck around with the content of the .svn repos, the only direct manipulation of them users have a use for is stripping them for exports or because somebody did not `svn export` and sent .svn folders where they did not belong.

Oh, and svn has had a full-featured client library[1] (and bindings for most popular languages[2]) for a very long time, so people have rarely needed to essentially reverse-engineer the interaction process from a checked-out working copy.

edit: now that I think about it further, your very observation is proving the complexity of git, or at least of git's UI: it's not expected that users of svn ever go muck around with their .svn (and as I explained there really is no reason to), so there is no wondering or audience about that, whereas not only is it expected that git users understand the content of their .git, it's pretty likely it will become necessary at one point in your usage of git, because you'll have no other way (learning the plumbing by rote is not an option until you've even done that, since it can only be understood if you know how git's store works, you'll just end up learning both anyway)

[0] http://svnbook.red-bean.com/en/1.1/ch07s02.html

[1] http://svn.apache.org/repos/asf/subversion/trunk/subversion/

[2] http://svn.apache.org/repos/asf/subversion/trunk/subversion/...

Re: Git Is Simpler Than You Think

#30

Post by vailripper »

Having used Mercurial and Git, I have to say I vastly prefer the interface of Mercurial. It still has its quirks, but overall I find it much easier to use, especially on Windows. Git was very clearly built as a Unix solution first, with Windows support hacked on later.
Post reply on HN