Request: `git restore $commit $file` shouldn’t override uncommited changes
- From
Robin Moussu <moussu.robin@pm.me>
- Date
- Apr 27, 2021, 17:37 UTC
- Message-ID
- <pYZzGPZTHnJjYBKrUAVGcso74I_xJgfzNpSwDN94fhYcDoOamp62-IFvxVrU056uw0txy3MTHYSwny_II0XY4trSY5_E25q7EXwhNHjy3VY=@pm.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.