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

71–80 of 122 posts

Re: Git Is Simpler Than You Think

#71

Post by jrockway »

fsniper wrote: post #5
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.

Yes I'm with you with this wccrawford. Git is not simple. Git internals may be simple hacks for hackers but git usage is another story. It does have neither understandable nor compatible terminology. Because it's simple bash scripts but distributed and decentralised it has a steep learning curve. No, no git is not simple. It's really complicated.

Git is mostly not bash scripts anymore:

    [~] 0 (jon@snowball2)
    $ file /usr/lib/git-core/git-status
    /usr/lib/git-core/git-status: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.26, stripped

Re: Git Is Simpler Than You Think

#72

Post by jrockway »

VilleSalonen wrote: post #49

I 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. :(

This line is irrelevant debugging information. The problem is that there's a merge conflict. This would happen with any version control system; it's not something unique to Git.

Re: Git Is Simpler Than You Think

#73

Post by fr0sty »

tedunangst wrote: post #66
fr0sty wrote: post #62

Earlier quoted context omitted.

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…

He didn't say the repo would be too huge for the server where the svn repo lives today. He said it would be too huge for the laptops. The binaries are already deduped, that's why they live in svn.

The OP made no mention of how large the SVN repo is, but rather speculated that the git equivalent would be "100s of GBs".

Had the statement been: "Our SVN repo is alreay 100s of GBs in size" then yes you are not likely to want to stuff that onto a laptop but that was not the claim. The claim (without rationale) was that the git equivalent would be 100s of GBs which is similar but not at all the same.

one assumse 1:1ish correspondence the other applies an unstated multiplier SVN * n = git where n > 1 (and significantly so.)

In reality the multiplier appears to be negative in many cases:

> Git's repositories are much smaller than Subversions(sic) (for the Mozilla project, 30x smaller) [1]

[1] https://git.wiki.kernel.org/index.php/GitSvnComparison

Re: Git Is Simpler Than You Think

#74

Post by honeyman »

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.

The worst thing in Git (comparing to Mercurial/other DVCSes) is that it is "more mainstream", thanks to GitHub. Everyone is assumed to have an account on GitHub (and such an account is even requested in the YC application form!), even if one is a Python programmer fond of Mercurial, or a Haskellista using darcs for everything around.

Re: Git Is Simpler Than You Think

#75

Post by oacgnol »

Git is very powerful and I do like it more than SVN, but I felt like I had more trouble switching to it from SVN than if I had learned git from a clean slate. Switching my mindset from SVN-style centralized repos to decentralized git was the hardest part, as certain things in SVN didn't translate to git. Git is simple, but switching is not.

Re: Git Is Simpler Than You Think

#76

Post by ph0rque »

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…

Good advice. I would add the following use case:

    # Oh no! Those changes should have been on their own branch, not dev...
    git stash
    git checkout -b changes_on_their_own_branch
    git stash apply
    git commit -a

Re: Git Is Simpler Than You Think

#77

Post by ajross »

rictic wrote: post #45
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".

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.

All true. Certainly nothing is "messed up".

That said, reading through a bunch of fine-grained and uninformative merge commits when looking at a log is really annoying. Serious projects expect submissions to be in the form of clean patch sets that apply in series and "look like" an instantaneous change. No one cares about per-developer histories.

If you look at the kernel history, for example, the only merge commits you see are Linus's and the subsystem maintainers'.

Re: Git Is Simpler Than You Think

#78

Post by rjh29 »

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…

To checkout an existing branch, you need only do 'git checkout new_branch_name' - if the branch exists on the remote, git will automatically create a local version and set it to track the upstream version.

Re: Git Is Simpler Than You Think

#79

Post by fr0sty »

ph0rque wrote: post #76
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…

Good advice. I would add the following use case: # Oh no! Those changes should have been on their own branch, not dev... git stash git checkout -b changes_on_their_own_branch git stash apply git commit -a

That is overly verbose. Try this:

    git checkout -b changes_on_their_own_branch
    git commit -a
You can always create a new branch at HEAD (where you are currently) and switch to it without having to stash.

On the other hand, stashing may be required if you wanted your branch to start elsewhere:

    git checkout -b changes_branch start_point
Post reply on HN