From: George Spelvin Date: Mon, 28 Sep 2015 23:52:09 GMT Subject: Re: Why not git reset --hard ? Message-ID: <20150928235209.29725.qmail@ns.horizon.com> In-Reply-To: Junio C Hamano wrote: > "George Spelvin" writes: >> "git checkout " modifies the index? >> >> Damn, I've been using git for years and I never knew that. > > ... which would be an indication that the behaviour is most likely > the most natural one. I think it's more that often, staging a file to the index is pretty harmless, so it doesn't actually matter. Both of the commonest forms of commit ("git commit -a" and "git commit [-o] ") aren't affected, and if I'm doing something trickier, I'll usually examine the status and make sure I've got it right. So I could have encountered it and put it down to fat-fingering on my part. >> But I just tested, and it does. Damn, now I have to figure out >> how to "leapfrog" a file from history into the working tree without >> overwriting the index; that's occasionally useful. > ... and indeed it is useful in some rare cases. Either > > git diff | git apply -R > > or > > git checkout && > git reset The former would work, and thanks for the idea, but for a single file I'd probably do one of git show : > git cat-file blob : > The checkout/reset wouldn't work in the case I'm thinking about, which is when I want to import a small piece (say, helper function that got deleted) from an old or other-branch version of a file. I.e. a partial revert or cherry-pick. If I had some current changes to merge with, I'd stage them, pull the *other* version into the tree, and use something like git-gui to add the hunk I want to the staged version. The whole point is that the staged state is important and I don't want it overwritten. There are other ways, of course: - Show or cat-file the other version into a temporary file and manually copy and paste. No need to stage anything. - Commit the current change, then add the additional changes and amend the commit.