CODEWITHSUNDEEP
gitversion-control
luca.p.alexandru
luca.p.alexandru

Reputation: 1750

Understanding how git works

Let's say I have two local repositorys, repo1 and repo2 both containing file1.txt with lines:

line1
line2
line3
line4

and that both are up to the latest branch. Repo1 does a a modification:

line3
line4

commits and pushes and repo2 does a pull without comitting (It didn't made any changes). When repo2 does the pull, shouldn't there be any comparison between the newly fetched file and the file in the local storage? I am using Sourcetree as a git GUI. This is what I observed from using it. Can anyone please clarify this for me please?

Upvotes: 2

Views: 270

Answers (2)

mellowfish
mellowfish

Reputation: 674

Unless your configure your repository differently or tell git to explicitly create a merge commit when you issue the pull or merge commands, git usually "fast forwards" certain types of merges that can be applied cleanly.

This prevents you from gunking up your history with "useless" merge commits.

Edit:

If you would like to always have a merge commit, you can specify --no-ff when you do a git pull. There is probably also an option to do this in your GUI preferences window.

Upvotes: 0

poke
poke

Reputation: 387667

When repo2 does the pull, shouldn't there be any comparison between the newly fetched file and the file in the local storage?

A pull happens in two phases: The first phase is just fetching the changes from the remote repository. This is a completely non-destructive action. If anything, it will add unique objects to your repository, expanding the object database. It will also update the remote branches which are essentially branches of the remote you are fetching from.

The second phase is a merge. Git will first check what changes have been made locally. As you didn’t commit anything else, there are no diverging changes and no merge is required. As such, Git can just update your local branch’s history to match the remote’s. At this stage, Git will also attempt to check out the changes so that your working directory will match the just pulled state. In case of a clean working directory, that means that there are no local changes of tracked files, there is no problem: All changes that might have been done before have been committed and won’t get lost. So Git will just update the local branch and check the new files out. In case there are local changes, your working directory is empty. Git will then check which files actually would need to be updated. If it can do that easily, it will do it and keep your changes the way they are. In doubt, it will raise an error that your working directory is not clean and abort everything.

So regardless of what’s the case, you will never lose anything.

Upvotes: 2

Related Questions