Hi,

On Thu, 18 Apr 2019, Junio C Hamano wrote:

> Duy Nguyen <pclouds@gmail.com> writes:
>
> > On Thu, Apr 11, 2019 at 8:12 PM Nguyễn Thái Ngọc Duy <pclouds@gmail.com> wrote:
> >>
> >> This is the companion of "git switch" and is based on that topic.
> >> This command peforms the "checkout paths" from git-checkout, git-reset
> >> and also has a third mode to reset only worktree, leaving the index
> >> alone.
> >
> > It does not have to be done now. But I'm just wondering, does anyone
> > think adding --dry-run is a good idea? This command is destructive by
> > default, so careful people might want it, I dunno.
>
> Yeah, "give --dry-run for anything potentially destructive" may be a
> good general principle, although we'd need to know where to stop.
> For example, I am not sure if "git reset --hard -n" would make all
> that much sense, as the sole point of running "reset --hard" is "I
> made an unrecoverable mess---get me back to a clean and known state
> no matter what" and in that context, "let me see which files in the
> working tree will be removed and checked out of the tree-ish and
> which paths in the index records a different blob than what is in
> the tree-ish, before deciding if I still want to stay in the
> unrecoverable mess or I want to get out of it" is something you
> could request, but at the same time, there is not much point in
> actually asking it.  Of course, a --dry-run that is not used often
> simply because it is not all that useful in practice is fine to have
> as long as it works correctly---I am saying that it's not something
> I'd personally prioritize myself.
>
> It would be an excellent addition to "restore-path" (and also to
> "checkout [<tree-ish> [--]] pathspec") to give "--dry-run".  Not
> just because it is destructive, but because unlike "reset --hard",
> it is selectively destructive.  Having a way to make sure that the
> given pathspec touches only the paths that the user intends to
> recover from the tree-ish or the index would be valuable.
>
> But it is a new feature, and I'd think it can (and probably should)
> be done as a follow-on series outside the main series you have been
> working on.  Let's make sure that we have the basics ready by the
> end of this cycle.

Since this command is supposed to make our not-quite-user-friendly
command-line interface a lot more user-friendly, I think that we should
take a step back and think very hard about a way to make this recoverable
an action.

The recently discussed project to make `git stash` handle unmerged index
entries should be a good step in that direction.

And I do not think that it would make a lot of sense to advance this
feature prematurely, i.e. without this safety hatch firmly in place.

Ciao,
Dscho