13

Running a git pull created some untracked files in my local copy. The files were moved on the remote, but the pull didn't remove the files in my working directory. I've spent quite a bit of time researching this, but can't find any similar cases. Is this intended behavior, am I missing something, or both?

Background

I made a patch and sent it to the devs of an open source project, but then I wanted to remove my local commit and git pull the "official" patch once it got committed on the remote. So I did a bunch of "stuff" to reset to the previous official HEAD. "Stuff" means things like git checkout -- <file>, git reset HEAD^, and other commands I cannot remember as I'm new to git and I'm trying to research best practices.

At any rate, after I finally "undid" my commit and did a git pull, I got 66 commits worth of changes, including my patch, and everything looked great. But then git status showed that two files were untracked. I did a gitk <untracked_file1> and I saw that about 20 commits back, the file was moved to another directory. The file now exists in the new location, but instead of deleting the old file, it shows up as untracked.

I tried doing a hard reset by following these instructions, but the files remain untracked. I can do a git clean -f to clear them out, but I'm wondering why the files aren't automatically removed.

Community
  • 1
  • 1
SO_fix_the_vote_sorting_bug
  • 412
  • 1
  • 5
  • 14
  • If the files now "live" at another location, you should be safe to just delete them. – Tim Biegeleisen Feb 22 '16 at 04:50
  • 2
    Indeed, I ran `git clean` right after I confirmed the files were moved. It just seems odd that the pull didn't remove them for me. – SO_fix_the_vote_sorting_bug Feb 22 '16 at 07:06
  • Well for all Git knows, you might intend to add those files again. So perhaps Git be playing it safe by not deleting such files. – Tim Biegeleisen Feb 22 '16 at 07:09
  • Ah, so perhaps it is intended behavior. I need to recheck the manuals. Git is pretty good at preventing me from making dumb mistakes... – SO_fix_the_vote_sorting_bug Feb 22 '16 at 18:03
  • 1
    I can confirm that TortoiseGit does remove the moved files. I have the same repository cloned on a Linux machine and on Windows. Another user had moved some directories to another place in the repo, for housekeeping purposes. I did ```git pull``` on both machines, or to be more precise, I did ```git pull``` on Linux and I did ```*right-click*->Git Sync...->Pull``` on the repo folder in Windows. In Linux I had 3 directories left in the repo root folder shown as "untracked", while in Windows they were gone. Would be great to know the reasoning behind the git behaviour and/or the TortoiseGit one. – zerzevul Jan 07 '21 at 11:54

3 Answers3

14

git pull doesn't delete uncommitted changes, it doesn't deal with your working directory, any changes or new files will not be touched unless it committed.

to learn more about the States of any git repo, Read this :
https://git-scm.com/book/en/v2/Getting-Started-Git-Basics

and also, to reset your local branch to match the remote one, instead of the "bunch of stuff", you can use this commands :
git fetch --all
git reset --hard origin/<remote_branch_name>

Ahmed Kamal
  • 561
  • 6
  • 17
  • i used two commands you mentioned, git fetch --all git reset --hard origin/ and there are untracked files shown when i use `git status` how? – Aayush Neupane Mar 10 '21 at 08:53
  • 1
    @AayushNeupane git is not going to do anything with untracked files, they are untracked means git is not tracking them, so no git command can do anything to the untracked files. – raj240 Mar 09 '22 at 07:06
2

Ahmed Kamal's answer did not change a thing in my case for a similar problem. I used git clean -f <folder_name> which successfully removed the folder from the files I was tracking.

JavaProScript
  • 106
  • 8
0

Another option is to keep removing one commit and keep jumping to the previous commits where these unstaged modified files are not showing up and finally perform a Pull operation as shown below:

ebanhhu@ebanhhu-vwcg:/home/epatdeb/uc$ git reset --hard HEAD~1

HEAD is now at 1e6c89a I.adoc

ebanhhu@ebanhhu-vwcg:/home/epatdeb/uc$ git reset --hard HEAD~1

HEAD is now at xxxxx

ebanhhu@ebanhhu-vwcg:/home/epatdeb/uc$ git reset --hard HEAD~1

HEAD is now at abc

And finally perform a Pull:

ebanhhu@ebanhhu-vwcg:/home/epatdeb/uc$ git pull
Deb
  • 587
  • 4
  • 12