On Tue, Dec 4, 2012 at 9:46 PM, Junio C Hamano <gits...@pobox.com> wrote:
> Martin von Zweigbergk <martinv...@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
> 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
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".
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html