* Request: `git restore $commit $file` shouldn’t override uncommited changes
@ 2021-04-27 17:37 Robin Moussu
2021-04-27 19:29 ` Johannes Altmanninger
2021-04-28 7:23 ` Junio C Hamano
0 siblings, 2 replies; 5+ messages in thread
From: Robin Moussu @ 2021-04-27 17:37 UTC (permalink / raw)
To: git
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Request: `git restore $commit $file` shouldn’t override uncommited changes
2021-04-27 17:37 Request: `git restore $commit $file` shouldn’t override uncommited changes Robin Moussu
@ 2021-04-27 19:29 ` Johannes Altmanninger
2021-04-28 8:35 ` Robin Moussu
2021-04-28 7:23 ` Junio C Hamano
1 sibling, 1 reply; 5+ messages in thread
From: Johannes Altmanninger @ 2021-04-27 19:29 UTC (permalink / raw)
To: Robin Moussu; +Cc: git
> 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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Request: `git restore $commit $file` shouldn’t override uncommited changes
2021-04-27 19:29 ` Johannes Altmanninger
@ 2021-04-28 8:35 ` Robin Moussu
2021-04-28 9:10 ` Junio C Hamano
0 siblings, 1 reply; 5+ messages in thread
From: Robin Moussu @ 2021-04-28 8:35 UTC (permalink / raw)
To: Johannes Altmanninger; +Cc: git
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Request: `git restore $commit $file` shouldn’t override uncommited changes
2021-04-28 8:35 ` Robin Moussu
@ 2021-04-28 9:10 ` Junio C Hamano
0 siblings, 0 replies; 5+ messages in thread
From: Junio C Hamano @ 2021-04-28 9:10 UTC (permalink / raw)
To: Robin Moussu; +Cc: Johannes Altmanninger, git
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Request: `git restore $commit $file` shouldn’t override uncommited changes
2021-04-27 17:37 Request: `git restore $commit $file` shouldn’t override uncommited changes Robin Moussu
2021-04-27 19:29 ` Johannes Altmanninger
@ 2021-04-28 7:23 ` Junio C Hamano
1 sibling, 0 replies; 5+ messages in thread
From: Junio C Hamano @ 2021-04-28 7:23 UTC (permalink / raw)
To: Robin Moussu; +Cc: git
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>".
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2021-04-28 9:10 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-04-27 17:37 Request: `git restore $commit $file` shouldn’t override uncommited changes Robin Moussu
2021-04-27 19:29 ` Johannes Altmanninger
2021-04-28 8:35 ` Robin Moussu
2021-04-28 9:10 ` Junio C Hamano
2021-04-28 7:23 ` Junio C Hamano
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).