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

5 messages from 2021-04-27 to 2021-04-28. Participants: Robin Moussu, Johannes Altmanninger, Junio C Hamano.
Thread: https://gitlist.dev/t/55571

## Robin Moussu, 2021-04-27 17:37

Subject: Request: `git restore $commit $file` shouldn’t override uncommited changes
Message-ID: <pYZzGPZTHnJjYBKrUAVGcso74I_xJgfzNpSwDN94fhYcDoOamp62-IFvxVrU056uw0txy3MTHYSwny_II0XY4trSY5_E25q7EXwhNHjy3VY=@pm.me>
URL: https://gitlist.dev/e/pYZzGPZTHnJjYBKrUAVGcso74I_xJgfzNpSwDN94fhYcDoOamp62-IFvxVrU056uw0txy3MTHYSwny_II0XY4trSY5_E25q7EXwhNHjy3VY%3D%40pm.me

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


```

## Johannes Altmanninger, 2021-04-27 19:29

Subject: Re: Request: `git restore $commit $file` shouldn’t override uncommited changes
Message-ID: <20210427192906.7obdkopxwajqnv53@gmail.com>
URL: https://gitlist.dev/e/20210427192906.7obdkopxwajqnv53%40gmail.com
In-Reply-To: <pYZzGPZTHnJjYBKrUAVGcso74I_xJgfzNpSwDN94fhYcDoOamp62-IFvxVrU056uw0txy3MTHYSwny_II0XY4trSY5_E25q7EXwhNHjy3VY=@pm.me>

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

```

## Junio C Hamano, 2021-04-28 07:23

Subject: Re: Request: `git restore $commit $file` shouldn’t override uncommited changes
Message-ID: <xmqqbl9yc1o6.fsf@gitster.g>
URL: https://gitlist.dev/e/xmqqbl9yc1o6.fsf%40gitster.g
In-Reply-To: <pYZzGPZTHnJjYBKrUAVGcso74I_xJgfzNpSwDN94fhYcDoOamp62-IFvxVrU056uw0txy3MTHYSwny_II0XY4trSY5_E25q7EXwhNHjy3VY=@pm.me>

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


```

## Robin Moussu, 2021-04-28 08:35

Subject: Re: Request: `git restore $commit $file` shouldn’t override uncommited changes
Message-ID: <I_ZK84DfFkUoO9FcqjidSjmsvktNt-k4tPiAGNIP5ztKjk0RQCfFmyRrRHaB414UaWsJO7kWPBcgHlRqAecH7r9mAj0TLm5k6T5_YzmiZ4c=@pm.me>
URL: https://gitlist.dev/e/I_ZK84DfFkUoO9FcqjidSjmsvktNt-k4tPiAGNIP5ztKjk0RQCfFmyRrRHaB414UaWsJO7kWPBcgHlRqAecH7r9mAj0TLm5k6T5_YzmiZ4c%3D%40pm.me
In-Reply-To: <20210427192906.7obdkopxwajqnv53@gmail.com>

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


```

## Junio C Hamano, 2021-04-28 09:10

Subject: Re: Request: `git restore $commit $file` shouldn’t override uncommited changes
Message-ID: <xmqqy2d2ai5w.fsf@gitster.g>
URL: https://gitlist.dev/e/xmqqy2d2ai5w.fsf%40gitster.g
In-Reply-To: <I_ZK84DfFkUoO9FcqjidSjmsvktNt-k4tPiAGNIP5ztKjk0RQCfFmyRrRHaB414UaWsJO7kWPBcgHlRqAecH7r9mAj0TLm5k6T5_YzmiZ4c=@pm.me>

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



```