Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Disambiguation similar behaving git commands checkout -- and restore

Tags:

git

So for years I have been using a subset of git commands that served me well. But I need to know the difference and preferred use of two very similar behaving commands. So.

When I have edits in one or more files that are checked into the repository and I want to remove all those edits (edits have not been staged), I use the command:

git checkout -- <path>

But apparently there's a more modern alternative.

git restore --source=HEAD --staged --worktree <path>

Is git checkout -- <path> going to be deprecated at some point? What is the difference between the two?

like image 959
hasdrubal Avatar asked May 31 '21 14:05

hasdrubal


People also ask

What is the difference between git checkout and git restore?

git-restore does not only substitute git checkout but also other commands, becoming the missing link to manage the changes in the tree. Usually, in order to add a file in git, you use git add/rm <file> . Or more often, git add .

What is git checkout and git checkout?

The git checkout command lets you navigate between the branches created by git branch . Checking out a branch updates the files in the working directory to match the version stored in that branch, and it tells Git to record all new commits on that branch.

What is the opposite of git checkout?

The git checkout command can be used in a commit, or file level scope. A file level checkout will change the file's contents to those of the specific commit. A revert is an operation that takes a specified commit and creates a new commit which inverses the specified commit.


1 Answers

The main difference in behavior between the two commands :

git restore --source={xxx} [--worktree] [--staged] -- <path>
# and
git checkout {xxx} -- <path>

is

  • git restore will delete files that are not present in {xxx},
  • git checkout will not touch these.

So git restore has the desired behavior "restore that file/that directory to its exact state in commit {xxx}", with more room for accidental deletion.

Depending on the options you use (--worktree and/or --staged), the deletion will happen on disk and/or in the index. There also is a --overlay option to prevent deletion (and basically behave like git checkout {xxx} -- <path>).


git checkout is so much part of git (so many scripts depend on its current behavior), it is IMHO extremely unlikely that it changes behavior in such a drastic way.

like image 115
LeGEC Avatar answered Oct 08 '22 02:10

LeGEC