git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / Atom feed
* Is git-checkout's restoring d/f conflict really sane?
@ 2019-05-14  9:41 Duy Nguyen
  2019-05-14 10:37 ` Junio C Hamano
  0 siblings, 1 reply; 4+ messages in thread
From: Duy Nguyen @ 2019-05-14  9:41 UTC (permalink / raw)
  To: Git Mailing List

$ echo data > one
$ git add one
$ rm one
$ mkdir one
$ echo two > one/two
$ echo three > one/three
$ git checkout one
$ ls -l one
-rw-r--r-- 1 pclouds pclouds 5 May 14 16:36 one

Replacing a file is one thing. In this case we're deleting a directory
and unknown number of files inside (in this case 'two' and 'three').
Is this really a good thing to do?

If it's not but too late to do anything about git-checkout, could
git-restore do something better (and exactly what)?
-- 
Duy

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Is git-checkout's restoring d/f conflict really sane?
  2019-05-14  9:41 Is git-checkout's restoring d/f conflict really sane? Duy Nguyen
@ 2019-05-14 10:37 ` Junio C Hamano
  2019-05-14 10:49   ` Duy Nguyen
  0 siblings, 1 reply; 4+ messages in thread
From: Junio C Hamano @ 2019-05-14 10:37 UTC (permalink / raw)
  To: Duy Nguyen; +Cc: Git Mailing List

Duy Nguyen <pclouds@gmail.com> writes:

> $ echo data > one
> $ git add one
> $ rm one
> $ mkdir one
> $ echo two > one/two
> $ echo three > one/three
> $ git checkout one
> $ ls -l one
> -rw-r--r-- 1 pclouds pclouds 5 May 14 16:36 one
>
> Replacing a file is one thing. In this case we're deleting a directory
> and unknown number of files inside (in this case 'two' and 'three').
> Is this really a good thing to do?
>
> If it's not but too late to do anything about git-checkout, could
> git-restore do something better (and exactly what)?

The user said "I do not want whatever I have under name 'one' in the
working tree, and I want what I have as 'one' in the index instead",
so I tend to think that failing the request would be a disservice.

I suspect that this will become even more right thing to do, in the
new world where the no-overlay mode becomes the default.  Unlike
"checkout HEAD ."  that only adds to the set of paths in the working
tree, "restore HEAD ." will remove what's in the working tree and in
the index but not in the HEAD, no?


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Is git-checkout's restoring d/f conflict really sane?
  2019-05-14 10:37 ` Junio C Hamano
@ 2019-05-14 10:49   ` Duy Nguyen
  2019-05-15  1:56     ` Junio C Hamano
  0 siblings, 1 reply; 4+ messages in thread
From: Duy Nguyen @ 2019-05-14 10:49 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Git Mailing List

On Tue, May 14, 2019 at 5:37 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> Duy Nguyen <pclouds@gmail.com> writes:
>
> > $ echo data > one
> > $ git add one
> > $ rm one
> > $ mkdir one
> > $ echo two > one/two
> > $ echo three > one/three
> > $ git checkout one
> > $ ls -l one
> > -rw-r--r-- 1 pclouds pclouds 5 May 14 16:36 one
> >
> > Replacing a file is one thing. In this case we're deleting a directory
> > and unknown number of files inside (in this case 'two' and 'three').
> > Is this really a good thing to do?
> >
> > If it's not but too late to do anything about git-checkout, could
> > git-restore do something better (and exactly what)?
>
> The user said "I do not want whatever I have under name 'one' in the
> working tree, and I want what I have as 'one' in the index instead",
> so I tend to think that failing the request would be a disservice.

Except that sometimes the user has those "oops that's not what I
meant" moments (and I think it's more often "I want to restore _file_
'one'"). One tricky thing in this situation is (to me) one/two and
one/three are untracked and we generally do not touch them unless
requested.

Technically 'one' is still tracked (even if it's a directory) so what
we're doing is right. I'm just not sure if there's some big surprise
factor here. And whether it's better to pause and double check with
the user before deleting everything.

> I suspect that this will become even more right thing to do, in the
> new world where the no-overlay mode becomes the default.  Unlike
> "checkout HEAD ."  that only adds to the set of paths in the working
> tree, "restore HEAD ." will remove what's in the working tree and in
> the index but not in the HEAD, no?

Yes. It makes me really want 'git restore --diff [--stat]' just to
show what's going to be restored. A careful user may see something
unexpected and examine more before really doing 'git restore'.
-- 
Duy

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Is git-checkout's restoring d/f conflict really sane?
  2019-05-14 10:49   ` Duy Nguyen
@ 2019-05-15  1:56     ` Junio C Hamano
  0 siblings, 0 replies; 4+ messages in thread
From: Junio C Hamano @ 2019-05-15  1:56 UTC (permalink / raw)
  To: Duy Nguyen; +Cc: Git Mailing List

Duy Nguyen <pclouds@gmail.com> writes:

> Technically 'one' is still tracked (even if it's a directory) so what
> we're doing is right. I'm just not sure if there's some big surprise
> factor here. And whether it's better to pause and double check with
> the user before deleting everything.

I agree to all of the above, including the part "technically it is
correct", but more importantly "stop and double check".  

As changing between a directory and a non-directory is a rare event
anyway, I do not mind making it a bit more cumbersome and say "you
asked me to check out a regular file 'one', but you have a directory
'one', that has an unignored untracked file in it, so I'd refuse to
do so.  Come back after you removed them manually, or use the '--force'
option".

We should not refuse if 'one' is an empty directory or all files in
it are ignored, though.

Thanks.



^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, back to index

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-05-14  9:41 Is git-checkout's restoring d/f conflict really sane? Duy Nguyen
2019-05-14 10:37 ` Junio C Hamano
2019-05-14 10:49   ` Duy Nguyen
2019-05-15  1:56     ` Junio C Hamano

git@vger.kernel.org list mirror (unofficial, one of many)

Archives are clonable:
	git clone --mirror https://public-inbox.org/git
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git
	nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git
	nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git
	nntp://news.gmane.org/gmane.comp.version-control.git

 note: .onion URLs require Tor: https://www.torproject.org/

AGPL code for this site: git clone https://public-inbox.org/ public-inbox