Re: [RFC/PATCH 1/2] reset: learn to reset to tree

From: Martin von Zweigbergk <martinvonz@gmail.com>
Date: Dec 5, 2012, 12:58 UTC
Message-ID: <CANiSa6iirgUjiLMo-wkaT7B_vdaK6s5gQ-CfTqPnDGj_GarWsw@mail.gmail.com>
In-Reply-To: <7vtxs1kq4z.fsf@alter.siamese.dyndns.org>

On Tue, Dec 4, 2012 at 9:46 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 15 quoted lines

> Martin von Zweigbergk <martinvonz@gmail.com> writes:
>
>> More importantly, when is it desirable not to delete deleted entries?
>
> When I am trying to check out contents of Documentation/ directory
> as of an older edition because we made mistakes updating the files
> in recent versions, with "git checkout v1.9.0 Documentation/", for
> example.  Perhaps somebody had this bright idea of reformatting our
> docs with "= Newer Style =" section headers, replacing the underline
> style, and we found our toolchain depend on the underline style, or
> something.  The new files in the same directory added since v1.9.0
> may share the same mistake as the files whose recent such changes I
> am nuking with this operation, but that does not mean I want to
> retype the contents of them from scratch; I'd rather keep them
> around so that I can fix them up by hand.

I think I follow, but why, then, would you not have the save problem with hunks *within* files that have been added in the new version? Or is the only change to Documentation/ since the "broken" commit that a new file has been added? That seems like a rather narrow use case in that case? "git checkout -p" seems more generally useful (whether that command deleted deleted files or not). It feels like I'm missing something...

> I would have to say that it is more common; I do not recall a time I
> wanted to replace everything in a directory (and only there without
> touching other parts of the tree) with an old version, removing new
> ones.

It has happened a few times for me. I think this usually happens when I realize that I had a better solution for some subsystem (under some path) in some other branch (perhaps from a previous attempt at the same problem) or an in older commit. Knowing that "git checkout $rev $path" doesn't do what I expect and that "git reset --hard $rev $path" is not allowed, I think I would usually do "git reset $rev $path && git checkout $path".