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

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

[Robin Moussu]

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.

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

[Johannes Altmanninger]

> I would have expected that `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.

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.

> 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 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

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

[Robin Moussu]

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.

> 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

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.

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

[Junio C Hamano]

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

> On the contrary, if `--source $commit` is specified, I would like
> to get an error if $file has uncommitted changes.

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.

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

[Junio C Hamano]

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

> 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.

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>".