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 ." ?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
