Re: Suggestion: make git checkout safer

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 <eda@xxxxxxxxxxxxx>

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]