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

51–60 of 122 posts

Re: Git Is Simpler Than You Think

#51

Post by tedunangst »

barrkel wrote: post #41

The whole "downloading history of the repository onto your machine" thing about git is what makes it unworkable where I work. A normal checkout from SVN is over 3GB in size just for our team's tree. There are a number of binaries that get pulled in and updated for various reasons (SDKs, platform-specific binaries) and they are versioned for repeatable and automatable builds across branches, all self-contained with mi…

You're being downvoted for not using an HN approved workflow. Your workflow is inconceivable and therefore wrong.

Re: Git Is Simpler Than You Think

#52

Post by burgerbrain »

barrkel wrote: post #41

The whole "downloading history of the repository onto your machine" thing about git is what makes it unworkable where I work. A normal checkout from SVN is over 3GB in size just for our team's tree. There are a number of binaries that get pulled in and updated for various reasons (SDKs, platform-specific binaries) and they are versioned for repeatable and automatable builds across branches, all self-contained with mi…

Two words: git submodules.

Re: Git Is Simpler Than You Think

#53

Post by nfarina »

tedunangst wrote: post #50
nfarina wrote: post #47

Earlier quoted context omitted.

Git actually starts compacting your object database and creating super-efficient delta-compressed packfiles after a bit. You can still throw object files in there afterwards though, and it doesn't change the basic principles of operation.

Super-efficient delta-compressed packfiles of zip files are not, in fact, super-efficient.

Ah ha, yes, you are correct - but packfiles combine multiple blobs together to benefit from additional compression that you couldn't achieve by compressing each individually.

Re: Git Is Simpler Than You Think

#54

Post by watmough »

schleyfox wrote: post #25
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.

So if I have branched from master, onto experimental, and made several experimental changes that I want to actually use, then I can simply type:

    git merge master
    git branch master
from the tip of my experimental branch, and master will be moved up to the tip of the tree?

Re: Git Is Simpler Than You Think

#55

Post by latortuga »

hardtke wrote: post #40
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…

If I follow your workflow, my coworkers go ballistic. The problem is that the "git pull" messes up the revision history. I finally learned to use "git pull --rebase".

It only "messes up revision history" if you do your development on your remote tracking branch that multiple people are pushing to. If you keep your remote tracking branch clean (e.g. master), you can pull into master whenever you want, merge your changes from a local branch, and push it right back out. Done this way, you never have to use pull --rebase (which will rewrite local history).

This workflow actually works pretty well with your desired outcome as well - you can rebase your local branch against newly pulled changes on master. This will make all of your local branch merges look like fast forward merges on master (i.e. no merge commit, linear history).

Re: Git Is Simpler Than You Think

#56

Post by dcosson »

vailripper wrote: post #30

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.

Interesting - haven't ever used Mercurial but as far as Windows ports of Unix-based tools go I love the git interface. I always run it in standalone shell mode, and its shell has enough Unix commands built in that I haven't even had the need to install cygwin on my new PC yet. The "check out line endings as \r\n, check in as \n" feature is a neat touch as well (granted, any decent text editor handles both kinds of line endings, but still).

Re: Git Is Simpler Than You Think

#57

Post by joeyh »

barrkel wrote: post #41

The whole "downloading history of the repository onto your machine" thing about git is what makes it unworkable where I work. A normal checkout from SVN is over 3GB in size just for our team's tree. There are a number of binaries that get pulled in and updated for various reasons (SDKs, platform-specific binaries) and they are versioned for repeatable and automatable builds across branches, all self-contained with mi…

If you wanted to use git in this situation, rather than svn, I'd recommend using git-annex (http://git-annex.branchable.com/). It avoids those binaries bloating the history while still letting branches "contain" specific versions of them. You can set up a centralized annex that is eg, a bup repository (or a rsync server, or use S3) and git-annex pulls down the binaries from there on request.

Re: Git Is Simpler Than You Think

#59

Post by invisiblefunnel »

wcoenen wrote: post #48
hardtke wrote: post #40

Earlier quoted context omitted.

If I follow your workflow, my coworkers go ballistic. The problem is that the "git pull" messes up the revision history. I finally learned to use "git pull --rebase".

As a SVN user who is not afraid to use feature branches, this "no branching" workflow of many git users amuses me to no end.

I have found that branches are the default for git users working on any project larger than a toy.

Re: Git Is Simpler Than You Think

#60

Post by masnick »

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…

My point is that to a naive user googling to figure out what is going on, the dotfile element of svn is inscrutable.
Post reply on HN