0

I would like to perform something similar to an svn update operation with git. I have a remote repository which originates from a fork operation on a master repository. I cloned this remote repository and now have a local repository.

I started working in this local repository and modified some files, added some files and deleted some files. I have committed/staged nothing at this point. I would like to come up with a generic command which will allow me to revert the state of my local repository to how it is in my remote forked repository, but without deleting the files I added. More specifically, the operation (similar to an svn update should:

  • Revert all modified files to how they are in the remote repository
  • Add all files in remote repository which are deleted in local repository
  • Leave newly added files alone.

I thought that this was within the realm of the git checkout. When I run git checkout it shows that the files are added, deleted or modified, but when I run a git status again I get the same as what I got before running git checkout. Also browsing through my local repo I see that that deleted files are not added again.

Am I using git checkout wrong? Why doesn't my local repo go back to what it was before?

user32882
  • 5,094
  • 5
  • 43
  • 82

1 Answers1

1

If you have not yet staged the new files, the files are untracked. Untracked files will not be removed when resetting. You can reset using:

git reset master --hard

Please note hard resetting can be a little scary, make real sure you have no tracked changes you wish to keep!

See also: git reset --hard HEAD leaves untracked files behind

ikkentim
  • 1,639
  • 15
  • 30
  • Its scary if you have tracked changes you care about. For now I am still useless with git so I'm not making any commits/staging. So actually `git reset master --hard` is exactly what I need... – user32882 Feb 18 '19 at 16:13
  • Actually what does `master` stand for ? Is it my forked repository or the main repository? – user32882 Feb 18 '19 at 16:15
  • @user32882: `master` is a branch name. Your branch names are *yours* to do with as you will. What you need to know here ... well, there's a LOT :-) but you can start with this concept: a commit has a unique hash ID, across every repository everywhere. If you have that hash ID you have that commit. If Bob has the hash ID he has the commit too. Everyone with *that* ID has *that* commit. No other commit has the same ID, no matter who makes it where, everyone agrees on the hash ID. Meanwhile a branch *name* like `master` is *yours*, and what it does is to remember *one* hash ID for you! – torek Feb 18 '19 at 16:59
  • @user32882: hash IDs are big and ugly and impossible for humans to deal with, which is why we use names: branch names like `master` or tag names like `v2.1`. They remember the hash IDs for us. The thing about branch names is that when you `git clone` someone else's repository, your Git *changes* their branch names, so that they won't conflict with your names. So Bob's `master` is your `bob/master`, for instance. – torek Feb 18 '19 at 17:01
  • @user32882: `git reset` does *three* things: (1) changes the hash ID stored in one of your branch names. (2) resets what Git calls the *index*, which is the set of files that go into the *next* commit. (3) resets what Git calls the *work-tree*, which is the only place you can see and work with your files. – torek Feb 18 '19 at 17:02
  • Thanks a lot @torek. Quite a lot for my small brain to handle but very educational. I will have to read and reread your comments to fully understand :). I am sure they will also be helpful to others in the same spot... – user32882 Feb 19 '19 at 07:31