5

I am pretty new to Git, so apologies if I sound like a total noob.

I initially ran the following command:

git clone https://github.com/userx/projecty.git

I have been making changes on my workstation, none of which have been uploaded. There is one file that has been updated on github that I would like to sync to my workstation:

https://github.com/userx/projecty/blob/master/whatever/whatever.py

I have made some modifications to it locally, but they could/should be overwritten. I only want that one file refreshed on my workstation without touching anything else that I have done. Any ideas on how to do this would be appreciated.

Thanks!

dana
  • 17,267
  • 6
  • 64
  • 88
  • 1
    Looks like you can do that here: http://stackoverflow.com/questions/16230838/git-is-it-possible-to-pull-just-for-one-file What you're looking for is pulling a single file, not cloning. – bozdoz Jan 25 '14 at 03:19
  • Are you just trying to get the latest contents of that file, but as a locally modified (but not checked in) file? Maybe instead of asking some specifics of the git operation, let us know what you are trying to accomplish. – Raman Jan 25 '14 at 03:30
  • I added some more detail to my question. Does it make more sense now? – dana Jan 25 '14 at 03:38
  • @dana, yes I think so, thanks. See my answer and let me know if that does what you want. – Raman Jan 25 '14 at 03:38

2 Answers2

3

Assuming you just want to overwrite the contents of that file in your working copy (so that it will show up as "modified" in the output of git status, then you can do it this way:

  1. Update the remote tracking branches of your local repository using git fetch. This does not modify any local branches, nor your working copy:

    git fetch --all

  2. Use git show to obtain a copy of the file from the remote branch, and write that to disk by redirecting standard output:

    git show origin/master:whatever/whatever.py > whatever/whatever.py

By specifying origin/master you are copying the file from the remote tracking branch, which will be the latest version of that file as of the git fetch. You can of course redirect the standard output to overwrite the existing file as shown above, or to write the output elsewhere.

The git show command accepts other formats as well: see "SPECIFYING REVISIONS" in man gitrevisions.

Note that, as @bluefeet commented on their answer, if you commit this file to your local branch, and your local branch is intended to be merged with the remote master later, then your locally copied whatever/whatever.py will be in conflict with the changes from the remote tracking branch. So generally, you would only do this as a temporary measure to test something, or if you have no intent of merging your local branch with the remote master later.

Raman
  • 17,606
  • 5
  • 95
  • 112
  • 1
    Thanks! I am not sure if what you showed me was a hack or not, but it worked :) Very appreciative! – dana Jan 25 '14 at 03:44
  • 1
    Its not really a hack :) One of the most powerful features of git is the remote tracking branch, because it gives you access to the state of the remote repository (or repositories) at all times. From this state you can show individual files or trees at any revision, or merge in changes, or whatever you need. I think one of the biggest disservices to people learning git is not teaching `git fetch` and `git merge` combination *before* teaching `git pull` (which is equivalent), because git pull obscures how git uses remote tracking branches. – Raman Jan 25 '14 at 03:48
3

I'd suggest this approach:

# Undo your changes to whatever.py.
git checkout whatever/whatever.py

# Pack up all your other changes, saving them to a special stash area.
git stash

# Update your repo, getting the latest, including the latest whatever.py.
git pull

# Now restore you changes from the stash.
git stash pop

That should do it, and puts you in a good working state.

bluefeet
  • 381
  • 1
  • 7
  • No, this will update any other files that have been updated on the remote also. – Raman Jan 25 '14 at 03:53
  • @Raman: True, but reading between the lines I'm pretty sure this is what the poster wants. The other solution proposed, using `git show`, causes whatever.py to show in git as if the poster was the one that made all the changes to that file and could lead to very difficult conflicts down the road if it was to be committed. – bluefeet Jan 25 '14 at 03:55
  • True. I don't think this is what the OP wanted but your note about the potential future conflict if the local HEAD is not updated is a good one -- I added a postscript about it to my answer. – Raman Jan 25 '14 at 04:04