61–70 of 122 posts
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…
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…
Git will deduplicate all of your binaries across branches (and if you are clever, across repositories, but that's another story) so worst case you will only have one copy of any binary file no matter how many times it appears in your history.
That is not to say that git may be a poor fit for your current project+organization for other reasons but a blanket assumption of ("repository would be too huge") is not generally accurate.
Earlier quoted context omitted.
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?
To do what you are describing you would do this (or something similar:
git checkout master; git merge experimentalNo, 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.
Well, to be fair, the title is not 'Git Is Simple'. I'm just starting to really use Git and after reading this it seems a little simpler to me. Personally, I think Git is relatively simple as far as version control systems go, it's forgetting 5 years worth of knowledge of SVN and the nice visual tools that support it that is hard.
Have you tried Tower (http://www.git-tower.com/)? I used it briefly for a small project and thought it was nice, but didn't really have time to get to know it that well.
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.
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…
What is the disk footprint of the existing SVN repository? "100s of GBs"? git's worst case repository size is equal to or slighly larger (few % probably) compared to an SVN repository. Git will deduplicate all of your binaries across branches (and if you are clever, across repositories, but that's another story) so worst case you will only have one copy of any binary file no matter how many times it appears in your h…
The binaries are already deduped, that's why they live in svn.
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 li…
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 the pro git book a very good reading to understand git for the first time http://progit.org/book/
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…
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.
i tried to learn git and hg and i found that hg was so much more friendly to work with. when things go wrong in git, cryptic error messages are spawned and i have no idea what to do. when i do things in hg, error messages are actually helpful. even when things don't go wrong, hg constantly gives me helpful advice at the command line. example: after you do hg pull, it tells me that i need to do hg update. why can't gi…