Re: Suggestion: make git checkout safer

["Torsten Bögershausen" <tboegi@web.de>]

On 2015-06-03 11.55, Ed Avis wrote:
> Jeff King <peff <at> peff.net> writes:
> 
>> I would say the more "usual" way to use checkout like this
>> is to give specific paths. I.e., run "git status", say "oh, I need to
>> restore the contents of 'foo', but not 'bar'", and run "git checkout
>> foo". That works regardless of the type of change to "foo" and "bar".
> 
> That seems fine - a specific file is named and you clearly want to alter
> the contents of that file.  By analogy, 'rm foo' will silently delete it,
> but if you specify a directory to delete recursively you need the -r flag.
> OK, it's not a perfect analogy because the purpose of rm is to delete data
> and nothing else ;-).
> 
> If my personal experience is anything to go by, newcomers may fall into the
> habit of running 'git checkout .' to restore missing files.  In the old days
> I would often delete a file and then run 'cvs update' or 'svn update' to
> restore it.  That would fetch a fresh copy from the repository, and while
> it might do some kind of diff/patch operation on modified files, it would
> not simply throw away local changes.
> 
> 'git checkout .' seems like the analogous command, but it has much sharper
> edges.  I still think it should be safer by default, but if you decide
> against that then perhaps you need to create some way to restore missing
> files and not overwrite others.  'git checkout --no-overwrite'?  Then it
> could even be added to .gitconfig as the default for those who like it.
> 
> I have to say that as a newcomer to git I do not like the idea of creating
> a special undo log for git.  It would just be yet another concept to learn
> and another thing to add to the list of 'where is git hiding my data this
> time?'.  And the time when it would be useful - after some bungled operation
> that lost data - is just the time when the user is already confused and
> adding another semi-hidden stash of objects to the mix would befuddle them
> further.  If there is to be a backup made of local changes that get lost,
> and I agree it is a good idea, then it should be something stupid and
> completely obvious, such as saving the old file as 'foo.before_checkout.1'.
> 
This is what my Git says:

git status
On branch master
Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        modified:   A
        deleted:    B

(So it should be somewhat self-documenting)


I try to avoid things like "git reset --hard", and "git checkout .",
and often use "git stash" instead.

It may be that there is a chance to improve the documentation.

Just for curiosity:
From where did you got the information to run "git checkout ." ?