Re: Suggestion: make git checkout safer

Eric Sunshine [off-list ref] writes:

...
Again:

    ...`hello.c` will also be restored,...

quoted

 because the file globbing is used to match entries in the index
 (not in the working tree by the shell).

Thanks for a thorough review.  I agree with all the comments and
suggestions you gave.  Also, Ed, thanks for an attempt to improve
the documentation.

I think the biggest problem with this patch is that the tone of the
updated text is geared a lot more towards venting the initial
frustration of the writer than helping the readers of the document.

By explaining what the behaviour is meant to solve and help, the
readers would get useful information (e.g. "this is to be used to
restore pristine contents").  The same thing said in the negative
way only serve to unnecessarily repel readers (e.g. "this will
unconditionally overwrite and lose contents").

Technically, they are the descriptions of the same thing---in order
to restore pristine contents to the workng tree, you have to discard
the botched changes you made in the working tree, and that is done
"unconditionally" by "overwriting" and "losing contents".  But
saying it in the negative way does not serve as a useful warning.

The readers are intelligent, and they will understand (and will even
appreciate) that a request to replace their botched contents in the
working tree out of the index is done unconditionally without being
asked an unnecessary "are you sure?" and done by overwriting the
files, losing the botched contents from there, once they are
explained why they want to "git checkout $paths", what the operation
is meant to be used for.

Perhaps taking a deep breath and waiting for a few days for the head
to coll down and frustrations to dissipate may be a good thing to do
;-)

I'm not attached to the wording changes posted earlier.  As I said, it is
only a starting point.

I do feel that 'git checkout PATH' is rather a dangerous operation, and
moreover a surprisingly dangerous one, since 'git checkout BRANCH' is
careful not to lose local changes, as are other common commands like
'git pull'.  In the documentation patch I tried to highlight the
distinction between the two rather different, and perhaps even
Jekyll-and-Hyde-like, modes of this command.

But rather than adding heavyhanded and redundant warnings to the
documentation it would be better for the command not to be quite so
sharp-edged.  There is already a --force option for one mode, which could
easily be made to apply to the other too (so local changes will not be
discarded unless --force is given).  Is the only argument against it that
'git checkout is intended to overwrite changes'?  That seems a little
circular since the question is whether its intended behaviour could change
to something a little safer.  Surely a sensible Huffman-coding of git
commands would give longer and harder-to-type names like 'git checkout
--force .' to relatively dangerous operations?

Or indeed, split out the two different modes into two separate commands.
The job of reverting file contents seems like something for 'git clean'.

I've said all I have to say but I would like to ask, in the hope of becoming
a better git user: if 'git checkout .' is not a safe way to restore missing
files in the working tree, what is the recommended way to do that?

Thanks all for your comments and guidance.

-- 
Ed Avis [off-list ref]