Request: `git restore $commit $file` shouldn’t override uncommited changes

Hello, That’s the first time I’m interacting with the git community, I’m not very familiar with the process. I hope I’m at the right place for a feature request.

Currently, I don’t think that it’s possible to get an error when copying the content of a file from another revision into your working tree if said file has uncommitted changes.

I recently discovered that `git restore` was introduced to make file manipulation less confusing than with `git checkout`. I know it was introduced a few years ago, I’m late to the party! I would have expected that the semantic of `git restore` or `git restore $file` would discard all uncommitted changes (you are restoring the file after all), while `git restore $commit $file` would copy the content of said file from another revision only if your don’t have uncommitted changes or to get an error. If it was really what I wanted to do, I would have expected to either do `git restore $file && git restore $commit $file`, directly `git restore --force $commit $file` or something similar.

Is my expectation wrong? Would it be worth considering adding an option in `.gitconfig` to have such behavior?

Sincerely, Robin.

The positional arguments to "git restore" are files. So that command will error unless a file called $commit exists. (You shell's tab completion should guide you here.) You can use the --source option to specify the commit.

Is your question that you expect a command like

	git restore --source=some-commit some-file

to error if you have uncommitted changes (to "some-file")? And instead you would run

	git restore some-file
	git restore --source=some-commit some-file

I effectively did a typo, I meant `git checkout $commit $file` or `git restore -s $commit $file`. I forgot the --source in the `git restore` command.

Exactly. If `--source $commit` isn’t specified, erasing uncommitted changes is what I expect. I scream-up, and want to start from a fresh state.

On the contrary,  if `--source $commit` is specified, I would like to get an error if $file has uncommitted changes. The reason I want to error when `--source $commit` is specified is because I most probably didn’t screw-up, but just forgot that I modified the file before copying its content from another revision.

Robin.

---

Should I wrap my text in 80 column? I’m not familiar with plain-text netiquette.

Robin Moussu <moussu.robin@pm.me> writes:

Not necessarily.  I've done this number of times:

 - start from the current state (HEAD), make changes

 - end up making a mess that I'd rather not use.

 - realize that the endgame I seek is fairly close to the work I did
   for another branch.

 - "git checkout $that_branch -- $those_paths".

So, it is not cut-and-dried that it _always_ (or even _often_) is a mistake to try overwriting a working tree file with modifiations with a version of a file from commit that is not HEAD. It may be _always_ an error for your work habit. It would almost always be what I want in my experience for me.

Robin Moussu <moussu.robin@pm.me> writes:

Yes, "git restore <from-where> <pathspec>" is like "I made a mess in the paths <pathspec> in the working tree and I want to start from a known state, so please take the contents for these paths from <from-where> and overwrite the garbage I have in the working tree".

It would be a grave regression to stop overwriting by default, as it misses the entire point of the command.

The same applies to "git checkout <from-where> -- <pathspec>".