0

I have a file which I had checkout out using previous git hash code using command :
git checkout 1a4f8901b3b3b52903ac7c8e7aa7a0a7ba95b4f1 -- example/abcxyz.php

now whenever I update any file and do git pull, git pull the command is unable to pull the above checkout file.

so if anyone can help me to get the latest commit of that file . And why it is not checkout that file?

Zoe
  • 27,060
  • 21
  • 118
  • 148
shashikant kuswaha
  • 520
  • 5
  • 13

2 Answers2

0

I am not sure what it is that you want to do with the checked out file. But here are possible solutions:

  • If you want to stash the checked out file

    git stash
git pull

  • If you want to remove the changes done to the file

    git checkout .
git pull

  • If you want to stage and commit the file

    git add example/abcxyz.php
git commit -m "commit message"
git pull

Let me know if any of these help you with your issue.

Gokul Chandrasekaran
  • 545
  • 3
  • 10
  • i have checkout previous version by above given command., but i think by default when i do git pull it should override that ```abcxyz.php``` file . but it is not happening ,why? – shashikant kuswaha Feb 20 '18 at 12:24
  • when running `git pull` it merges the changes from the remote. However when you've unstaged changes in your repository, it is impossible for `git` to merge the changes in the files. This is the expected behaviour. I'd recommend that you take a look at [git docs](https://git-scm.com/docs/git-pull) for more information. – Gokul Chandrasekaran Feb 20 '18 at 17:01
  • thanks ,... i can get the problem solved by again doing git checkout filename without specify version. like ```git chekout example/abcxyz.php``` – shashikant kuswaha Feb 21 '18 at 05:28
  • Cool. That is similar to the second scenario in my answer. – Gokul Chandrasekaran Feb 21 '18 at 07:37
0

git pull does not do what you think it does.

In particular, git pull does not "pull files" at all!

What git pull does is:

  1. run git fetch;
  2. run a second Git command, usually git merge.

The first command—the git fetch part of git pull—has your Git call up some other Git, usually the Git at the URL you have stored under the name origin. This other Git may have some commits that you do not have yet. If so, the other Git gives those commits to your Git, along with the branch names that the other Git uses to remember those commits. Your Git then renames their branches, so that your Git remembers their master under your name origin/master, their dev under origin/dev, and so on.

Having learned of any new commits they have that you don't, it's now possible for your Git to run git merge on one of those commit hash IDs. If you have not told it otherwise, your git pull command does that now.

A merge operation merges "what you did"—which in this case, includes "set this file back in time"—with "what they did". To do this, the merge must first find a commit that you share with them. If you're on your master branch, for instance, you might find the last commit you have that is also on your origin/master (this being your Git's way of remembering their master). Your Git can then compare:

  • What was in this old commit, and what's in your current commit? Whatever is different, you must have changed.

  • What was in this old commit, and what's in their current commit? Whatever is different, they must have changed.

If they did not change the file, and you did change the file—you did change the file, you said so yourself—then Git will keep your changes.

(Note that if you have not committed your changes, doing this kind of git merge is tricky and not a good idea. If you don't want your changes, you can discard them using git reset or git checkout; any reasonably modern Git will give you advice on this with git status. If you do want to keep your changes, you should commit them.)

torek
  • 448,244
  • 59
  • 642
  • 775