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

What's the difference between 'git pull' and 'git fetch'?

stackoverflow.com

Post reply on HN
Print view View original

11–20 of 29 posts

Re: What's the difference between 'git pull' and 'git fetch'?

#11

Post by oxtopus »

Consider that git is a database of snapshots-in-time with an interface to append your own snapshot(s), and a protocol for distributing the revised timeline to others.

`git fetch` is how you retrieve those changes from a remote (like github). `git pull` takes it a step further and attempts to merge your changes in automatically. Think of it as two separate "download" and "sync" operations, depending on your workflow, you may want to download, but defer the sync. Eventually, you will need to sync before sending your changes upstream (`git push`), but you have some flexibility in deciding when.

For example, if you are travelling, you may want to fetch your remote(s) so that you have access to a relatively recent copy of the remote, but you aren't ready to apply those changes to your current source tree. Or, you may want fetch the remote(s) and compare the differences before applying the changes locally in case there's risk of incorporating a breaking change that could disrupt things.

Re: What's the difference between 'git pull' and 'git fetch'?

#12

Post by tlitd »

shadowmint wrote: post #6

Why do so many people have such trouble with this simple concept? Git isn't complicated, you just have to understand that a git repository is composed of two things: 1) The index which is the git information about all your files (ie. .git/) 2) The files you currently have checked out. When you git fetch, you update the index, nothing else. When you git merge or git rebase or reset or checkout, you update your files f…

And you don't understand what the index is. And because of that you are confusing people instead of helping them.

tednaleid already explained it in his reply to you.

Re: What's the difference between 'git pull' and 'git fetch'?

#13

Post by shadowmint »

tednaleid wrote: post #7
shadowmint wrote: post #6

Why do so many people have such trouble with this simple concept? Git isn't complicated, you just have to understand that a git repository is composed of two things: 1) The index which is the git information about all your files (ie. .git/) 2) The files you currently have checked out. When you git fetch, you update the index, nothing else. When you git merge or git rebase or reset or checkout, you update your files f…

The index isn't the information on all your files (it's not the .git directory). The index is an intermediate holding location between the file system and actually storing all of those files as a commit in the commit tree. It's the current state of the proposed next commit. Your description misses (or conflates) an entire tree of information (the HEAD tree), and it's arguably the most important one as it holds the wh…

Ok, not the index. The point is:

You have repository meta data in your .git folder.

You can download new information into your .git folder using git fetch.

...but you can only apply changes to your .git folder's data locally (eg. git merge)

...and you can only apply changes to your file system from your local .git folder.

Four, basic concepts. Why is this difficult?

There's tonnes of complexity in git, sure, if you have trouble merging after a rebase, sure, that's totally understandable.

...but the basic failure to understand the difference between applying a remote change directly to your current file system (not possible) and downloading that change and then applying it locally in various ways frustrates me, I've got to say.

Re: What's the difference between 'git pull' and 'git fetch'?

#14

Post by ams6110 »

shadowmint wrote: post #6

Why do so many people have such trouble with this simple concept? Git isn't complicated, you just have to understand that a git repository is composed of two things: 1) The index which is the git information about all your files (ie. .git/) 2) The files you currently have checked out. When you git fetch, you update the index, nothing else. When you git merge or git rebase or reset or checkout, you update your files f…

Git isn't complicated

Yes it is. It's not necessarily incomprehensible, but it is absolutely more complicated than predecessor systems like svn. Simply compare the man pages and number of commands and options.

It makes me extremely sad to see this repeated over and over and people don't get it.

If this is the case, then existing explanations/documentation are lacking, or the system is fundamentally too complex for "people" to "get."

Re: What's the difference between 'git pull' and 'git fetch'?

#15

Post by ams6110 »

shadowmint wrote: post #13
tednaleid wrote: post #7

Earlier quoted context omitted.

The index isn't the information on all your files (it's not the .git directory). The index is an intermediate holding location between the file system and actually storing all of those files as a commit in the commit tree. It's the current state of the proposed next commit. Your description misses (or conflates) an entire tree of information (the HEAD tree), and it's arguably the most important one as it holds the wh…

Ok, not the index. The point is: You have repository meta data in your .git folder. You can download new information into your .git folder using git fetch. ...but you can only apply changes to your .git folder's data locally (eg. git merge) ...and you can only apply changes to your file system from your local .git folder. Four, basic concepts. Why is this difficult? There's tonnes of complexity in git, sure, if you h…

This might be best explained with pictures, which of course aren't really possible on a forum like this. The problem is when people try to explain git in words they often start talking about "directed acyclic graphs" and "local remote" or "remote local" branches (what?) and using terms like "clone", "checkout", "rebase", "master", "head", "origin" without defining them; terms that have specific meanings in git that are different from their meanings in other systems and different from what many uninitiated users might think they mean intuitively.

Re: What's the difference between 'git pull' and 'git fetch'?

#16

Post by ams6110 »

thejosh wrote: post #8
shadowmint wrote: post #6

Why do so many people have such trouble with this simple concept? Git isn't complicated, you just have to understand that a git repository is composed of two things: 1) The index which is the git information about all your files (ie. .git/) 2) The files you currently have checked out. When you git fetch, you update the index, nothing else. When you git merge or git rebase or reset or checkout, you update your files f…

It's not the same people not getting it. More and more people are using git every day so they are the ones who do not understand the git terminology/technology.

A lot of people use git without understanding it.

Re: What's the difference between 'git pull' and 'git fetch'?

#18

Post by anonyfuss »

shadowmint wrote: post #13
tednaleid wrote: post #7

Earlier quoted context omitted.

The index isn't the information on all your files (it's not the .git directory). The index is an intermediate holding location between the file system and actually storing all of those files as a commit in the commit tree. It's the current state of the proposed next commit. Your description misses (or conflates) an entire tree of information (the HEAD tree), and it's arguably the most important one as it holds the wh…

Ok, not the index. The point is: You have repository meta data in your .git folder. You can download new information into your .git folder using git fetch. ...but you can only apply changes to your .git folder's data locally (eg. git merge) ...and you can only apply changes to your file system from your local .git folder. Four, basic concepts. Why is this difficult? There's tonnes of complexity in git, sure, if you h…

> Four, basic concepts. Why is this difficult?

Because it's 3 more concepts than most people need.

A simple remote repository, coupled with a working copy, is easy to understand (and also all that most people really need).

You commit, you update. The only local divergences are the changes you haven't committed yet. In my experience, almost anyone can understand this semi-intuitively, and they only start getting confused when they hit merge conflicts.

Git, however, introduces considerable more state that a user must understand. There is local working copy state. There is local repository state. There is remote repository state. There is other people's remote repository state. Those states can become in conflict with one another, which means that there are quite a few more places to hit conflicts, and lots of sharp edges in the tool (git) with which you'd resolve them.

That's a lot of state, and it's state that most people don't actually need; it incurs a lot of mental overhead, even for people that understand how it works -- as evidenced by the fact that we're even having this conversation and two of you are debating how the index works.

The fact that this is git's default operating mode means that git is a bit like using a thermonuclear weapon to cook your breakfast, when most of the time, a simple gas stove would do. The tool was built for Linux, where it was designed to handle competing, divergent organizations, all of whom maintain long-term ongoing forks, with existing political and technical disagreements, divergent code bases and divergent ideas of stability and support requirements, all of whom are independently and concurrently maintaining, sharing, and rejecting patch sets across the graph of organizations participating in Linux development.

It's a huge, complicated, expensive, and messy development process, and it's nothing like what most organizations and projects need to support as their default mode of operation.

The problem isn't the people, the problem is that the tool is too damn complicated.

Re: What's the difference between 'git pull' and 'git fetch'?

#19

Post by daigoba66 »

I think an important aspect to "getting" git is realizing and accepting that git has several somewhat redundant commands and usually two or more ways to accomplish something.

Personally I always do "git remote update -p" to synchronize all my remotes and then explicitly merge or rebase depending on what I'm trying to do.

Post reply on HN