From: "Ed Avis" <eda@xxxxxxxxxxxxx>
Sent: Wednesday, June 03, 2015 10:55 AM
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'.
--
Ed Avis <eda@xxxxxxxxxxxxx>
To me, when I saw the 'git checkout .', I was reminded of the 'git push
. <refs>' special case where '.' is the repo, so in my mind the first
thought was that Ed wanted to checkout the head of the current repo, and
that should have barfed from that viewpoint.
The [is it equivalent? (rhet)] 'git checkout -- .' would clearly
indicate that the '.' refers to the files of the current directory
(wouldn't it?)
So it's about how '.' is perceived by the code in different
circumstances, and whether, perhaps, the optional discriminating '--'
should be required in this (special) case.
Philip
--
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