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 minimal dependencies. I dread to think what the entire history would take - it must be many 100s of GBs at least. It would certainly rule out the whole "working disconnected" idea on laptops, for one.
Git Is Simpler Than You Think
41–50 of 122 posts
Re: Git Is Simpler Than You Think
#42Having 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…
I used both, too.
From the mercurial docs: "If you felt uncomfortable dealing with Git's index, you are switching for the better."
To be honest, after a few years with git, I feel uncomfortable without the index.
Re: Git Is Simpler Than You Think
#43If 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?
It allows you to use `git pull/push' without specifying the remote. see: http://mislav.uniqpath.com/2010/07/git-tips/ Section "Push a branch and automatically set tracking"
Re: Git Is Simpler Than You Think
#44The 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…
But have you actually tried it? You might be surprised.
Re: Git Is Simpler Than You Think
#45If 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".
Technically speaking it doesn't "mess up" the revision history, it preserves it. Rebasing instead of merging creates a linear revision history, which is simpler and more similar to centralized version control, but at the cost of losing information about the actual path of development.
Re: Git Is Simpler Than You Think
#46The 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…
Can you maybe separate the binaries and use git for only sources?
Re: Git Is Simpler Than You Think
#47The 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 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.
Re: Git Is Simpler Than You Think
#48If 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".
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.
Re: Git Is Simpler Than You Think
#49I read through the article waiting for the explanation of the "Falling back to patching base and 3-way merge?" line but unfortunately it wasn't explained. Git didn't become any simpler after all. :(
Re: Git Is Simpler Than You Think
#50The 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 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.