From: Junio C Hamano <gitster@pobox.com>
To: Eric Sunshine <sunshine@sunshineco.com>
Cc: Ed Avis <eda@waniasset.com>, Git List <git@vger.kernel.org>
Subject: Re: Suggestion: make git checkout safer
Date: Fri, 05 Jun 2015 11:03:52 -0700 [thread overview]
Message-ID: <xmqqd21arq0n.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <CAPig+cTK4pXgweoGZc1-nj41aYo0bEK6Zrsc9291xQr5v8=p8g@mail.gmail.com> (Eric Sunshine's message of "Fri, 5 Jun 2015 13:44:50 -0400")
Eric Sunshine <sunshine@sunshineco.com> writes:
> ...
> Again:
>
> ...`hello.c` will also be restored,...
>
>> because the file globbing is used to match entries in the index
>> (not in the working tree by the shell).
Thanks for a thorough review. I agree with all the comments and
suggestions you gave. Also, Ed, thanks for an attempt to improve
the documentation.
I think the biggest problem with this patch is that the tone of the
updated text is geared a lot more towards venting the initial
frustration of the writer than helping the readers of the document.
By explaining what the behaviour is meant to solve and help, the
readers would get useful information (e.g. "this is to be used to
restore pristine contents"). The same thing said in the negative
way only serve to unnecessarily repel readers (e.g. "this will
unconditionally overwrite and lose contents").
Technically, they are the descriptions of the same thing---in order
to restore pristine contents to the workng tree, you have to discard
the botched changes you made in the working tree, and that is done
"unconditionally" by "overwriting" and "losing contents". But
saying it in the negative way does not serve as a useful warning.
The readers are intelligent, and they will understand (and will even
appreciate) that a request to replace their botched contents in the
working tree out of the index is done unconditionally without being
asked an unnecessary "are you sure?" and done by overwriting the
files, losing the botched contents from there, once they are
explained why they want to "git checkout $paths", what the operation
is meant to be used for.
Perhaps taking a deep breath and waiting for a few days for the head
to coll down and frustrations to dissipate may be a good thing to do
;-)
next prev parent reply other threads:[~2015-06-05 18:03 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-03 8:50 Suggestion: make git checkout safer Ed Avis
2015-06-03 9:06 ` Jeff King
2015-06-03 9:21 ` Ed Avis
2015-06-03 9:35 ` Jeff King
2015-06-03 9:55 ` Ed Avis
2015-06-03 17:35 ` Junio C Hamano
2015-06-03 17:49 ` Randall S. Becker
2015-06-03 18:11 ` Junio C Hamano
2015-06-03 18:18 ` Randall S. Becker
2015-06-03 18:14 ` Stefan Beller
2015-06-04 10:47 ` Ed Avis
2015-06-04 11:02 ` Ed Avis
2015-06-03 19:26 ` Torsten Bögershausen
2015-06-03 19:47 ` Kevin Daudt
2015-06-04 11:00 ` Ed Avis
2015-06-04 20:14 ` Torsten Bögershausen
2015-06-05 9:32 ` Ed Avis
2015-06-05 10:49 ` Duy Nguyen
2015-06-05 17:44 ` Eric Sunshine
2015-06-05 18:03 ` Junio C Hamano [this message]
2015-06-05 18:46 ` Ed Avis
2015-06-05 18:37 ` Eric Sunshine
2015-06-03 20:12 ` Philip Oakley
2015-06-03 17:32 ` Junio C Hamano
2015-06-03 19:06 ` Jeff King
2015-06-03 19:24 ` Randall S. Becker
2015-06-03 21:29 ` Junio C Hamano
2015-06-04 9:01 ` John Szakmeister
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=xmqqd21arq0n.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox.com \
--cc=eda@waniasset.com \
--cc=git@vger.kernel.org \
--cc=sunshine@sunshineco.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.