git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Martin von Zweigbergk <martinvonz@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [RFC/PATCH 1/2] reset: learn to reset to tree
Date: Tue, 04 Dec 2012 21:46:20 -0800	[thread overview]
Message-ID: <7vtxs1kq4z.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <CANiSa6iMxzQGM8mZYdfR-drPGgydwVpM5JsQ-8oO09MX5XDH+g@mail.gmail.com> (Martin von Zweigbergk's message of "Tue, 4 Dec 2012 19:45:47 -0800")

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 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.  "git checkout [$commit] $paths" is still an operation to help
me build new history forward starting from HEAD, and is not about
start building on top of the old $commit.  Losing the work I've done
to the files that did not exist in $commit:$paths is almost always
*not* what I would expect to happen with the command.

  reply	other threads:[~2012-12-05  5:46 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-27 17:25 Operations on unborn branch Martin von Zweigbergk
2012-11-27 20:25 ` Junio C Hamano
2012-11-27 20:39   ` Martin von Zweigbergk
2012-11-28  7:12     ` Junio C Hamano
2012-11-30 16:39       ` Martin von Zweigbergk
2012-11-29 18:32 ` [RFC/PATCH 0/2] Fix "git reset" " Martin von Zweigbergk
2012-11-29 18:32   ` [RFC/PATCH 1/2] reset: learn to reset to tree Martin von Zweigbergk
2012-11-29 18:47     ` Junio C Hamano
2012-11-29 19:04       ` Martin von Zweigbergk
2012-11-29 19:36         ` Junio C Hamano
2012-11-29 19:13       ` Junio C Hamano
2012-11-29 22:00         ` Martin von Zweigbergk
2012-11-30 16:45           ` Martin von Zweigbergk
2012-12-01  9:24             ` Junio C Hamano
2012-12-05  3:45               ` Martin von Zweigbergk
2012-12-05  5:46                 ` Junio C Hamano [this message]
2012-12-05 12:58                   ` Martin von Zweigbergk
2012-11-29 18:32   ` [RFC/PATCH 2/2] reset: learn to reset on unborn branch Martin von Zweigbergk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7vtxs1kq4z.fsf@alter.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=martinvonz@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).