Re: Suggestion: make git checkout safer

From: Ed Avis <eda@waniasset.com>
Date: Jun 4, 2015, 11:00 UTC
Message-ID: <loom.20150604T124827-124@post.gmane.org>
In-Reply-To: <20150603194756.GB29730@vps892.directvps.nl>

Kevin Daudt <me <at> ikke.info> writes:

>If people execute git checkout . as a habbit
>without thinking, they will soon train to do git checkout -f . without
>thinking, and then you still have the same problem.

I don't quite agree; you only learn to use the -f flag if the plain command doesn't do what you want. With rm, I want to remove that file, dammit! The -f flag is often a necessity to stop the tool getting in my way. But when fixing up a working tree, I rarely want to silently trash any local changes.

>I do share your sentiment that it's easy to loose uncomitted changes to
>git checkout <path>, but like Jeff said, the entire goal of this command
>is to reset specific files from the index or commits.

Well that's not quite the flavour given by the documentation, which says

    >Updates files in the working tree to match...

'Updating' files sounds like a fairly safe thing to do, right? Like 'cvs update' or 'svn update', which don't just overwrite working tree changes. The doc doesn't really make clear that any local changes will be discarded; indeed the only mention of that is

       -f, --force
         When switching branches... this is used to throw away local changes.

To the casual reader, following 'the exception proves the rule', it appears that local changes are not thrown away except in this case.

-- 
Ed Avis <eda@waniasset.com>