From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>,
James Pickens <jepicken@gmail.com>,
git@vger.kernel.org
Subject: Re: [PATCH] grep: --full-tree
Date: Sun, 29 Nov 2009 11:49:38 -0800 [thread overview]
Message-ID: <7v3a3x9kml.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <20091129183217.GB21520@sigill.intra.peff.net> (Jeff King's message of "Sun\, 29 Nov 2009 13\:32\:17 -0500")
Jeff King <peff@peff.net> writes:
> On Sun, Nov 29, 2009 at 11:28:27AM +0100, Johannes Schindelin wrote:
> ...
>> > When the number of "git grep" crash fatalities rises above zero, maybe
>> > this line of reasoning will be relevant.
>>
>> Sure. Let's wait for the first crash fatality, and only react then. No
>> need to think ahead.
>
> ... The actual situation
> at hand is a git grep configuration variable. I am weighing the
> preference of people who use git every day and want it to work in a
> certain way against the possibility that somebody helping them will be
> slightly inconvenienced or surprised.
While my position is *not* "hurting people who help is too grave and we
shouldn't even weigh other upsides against it---bad is bad is bad, and it
is absolutely bad" (which is what I think Dscho is saying), I think
"slightly inconvenienced or surprised" is trying to make it sound a lot
lighter than it is.
Imagine you are helping somebody to track down a bug in a project whose
source happens to be under git. You two scratch your heads together, and
you try to find if the function you are fixing have other call sites, and
you run "git grep" to find them. You think you covered the whole tree,
identified all the callsites and made sure that the updated behaviour of
the function with your fix is consistent with all of them. But it turns
out that you didn't check the whole tree, due to user's configuration, and
you didn't notice.
You can easily waste 30 minutes of two people until you realize what
happened. Because the whole point of your grep.fulltree configuration is
that you can set it once and forget about it, even after you noticed that
your grep didn't look in the whole tree as you expected, the configuration
variable is not the first thing that will come to your mind. You will
waste more minutes wondering why grep is not working as you expect, until
you finally come up with a suggestion to set the configuration to make
grep look in the full tree by default in her repository.
Put it another way, your "I can set it and forget about it" may be a way
to solve "differentiating two things is a mental burden and I do not want
to think about it". But I do not think the "mental burden" problem is
necessarily what we want to solve. The "set and forget" will bring
confusion.
The best solution to the "mental burden" problem may not even be "I can
set it and forget about it". An obvious solution to that problem, that is
far easier to explain, is not to have two things to begin with, and that is
what we do: "If you want to grep in the whole tree, you go to the top and
run grep there." Of course, its downside is that it is often cumbersome
to "got to the top" when you are somewhere deep.
That is why I think it would be a lot better solution to spend our efforts
making sure that both semantics can be called for from the command line in
a concise and clear way. IOW, the problem I see worth solving first is
not the "mental burden" problem, but is "differentiating two things is
necessary, but it is cumbersome to say which one I want."
You probably can add both configuration and concise command line syntax,
but "solving" the "mental burden" problem will make you forget about the
need to use --full-tree option (or its quivalent that will happen in the
solution of the "cumbersome to say which one I want" problem). On the
other hand, not "solving" the "mental burden" problem will hopefully train
your brain and your fingers to always be aware of and to say which one you
want, to the point that you do not even have to think.
For that to happen, "cumbersome to say which" problem must be solved
nicely, of course.
> ... Something that will happen much
> less frequently than the person actually _using_ git, and something
> which has much smaller negative consequences than people dying.
It is of course not _fatal_, but there are not many things that are fatal.
Saying "that is not fatal so it is Ok" is not particularly a good way to
weigh downsides against upsides.
next prev parent reply other threads:[~2009-11-29 19:49 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-24 8:56 [PATCH] grep: --full-tree Junio C Hamano
2009-11-25 13:16 ` Michael J Gruber
2009-11-25 19:32 ` Junio C Hamano
2009-11-25 14:56 ` Sverre Rabbelier
2009-11-25 19:32 ` Junio C Hamano
2009-11-25 20:19 ` Sverre Rabbelier
2009-11-25 20:23 ` Junio C Hamano
2009-11-25 20:46 ` Sverre Rabbelier
2009-11-25 23:31 ` Johannes Schindelin
2009-11-25 23:29 ` Sverre Rabbelier
2009-11-25 20:52 ` Jeff King
2009-11-25 20:39 ` Jeff King
2009-11-25 20:52 ` Junio C Hamano
2009-11-25 21:00 ` Jeff King
2009-11-25 21:33 ` Junio C Hamano
2009-11-25 21:49 ` Jeff King
2009-11-25 22:12 ` James Pickens
2009-11-25 22:20 ` Jeff King
2009-11-26 17:56 ` James Pickens
2009-11-27 6:20 ` Jeff King
2009-11-27 8:18 ` Junio C Hamano
2009-11-27 9:31 ` Johannes Schindelin
2009-11-27 9:59 ` Jeff King
2009-11-27 10:53 ` Johannes Schindelin
2009-11-27 16:27 ` Uri Okrent
2009-11-27 18:29 ` Junio C Hamano
2009-11-27 18:47 ` Uri Okrent
2009-11-27 20:53 ` Jeff King
2009-11-29 19:50 ` Uri Okrent
2009-11-29 11:48 ` Felipe Contreras
2009-11-27 18:02 ` Jeff King
2009-11-27 20:07 ` Johannes Schindelin
2009-11-27 21:05 ` Jeff King
2009-11-29 10:28 ` Johannes Schindelin
2009-11-29 18:32 ` Jeff King
2009-11-29 19:49 ` Junio C Hamano [this message]
2009-11-29 12:13 ` Felipe Contreras
2009-11-27 18:29 ` Junio C Hamano
2009-11-27 20:50 ` Jeff King
2009-11-29 10:21 ` Johannes Schindelin
2009-11-29 18:24 ` Jeff King
2009-11-27 10:37 ` Matthieu Moy
2009-11-27 10:56 ` Johannes Schindelin
2009-11-25 22:26 ` Wincent Colaiuta
2009-11-26 0:00 ` Junio C Hamano
2009-11-26 0:16 ` A Large Angry SCM
2009-11-26 0:20 ` Junio C Hamano
2009-11-26 0:30 ` A Large Angry SCM
2009-11-26 0:36 ` Junio C Hamano
2009-11-26 18:14 ` James Pickens
2009-11-25 22:19 ` Junio C Hamano
2009-11-25 22:26 ` Jeff King
2009-11-25 22:41 ` A Large Angry SCM
2009-11-25 22:53 ` Jeff King
2009-11-25 23:07 ` A Large Angry SCM
2009-11-25 23:22 ` Jeff King
2009-11-29 11:38 ` Felipe Contreras
2009-11-29 19:45 ` Uri Okrent
2009-11-26 0:02 ` Junio C Hamano
2009-11-27 6:22 ` Jeff King
2009-11-25 22:15 ` A Large Angry SCM
2009-11-25 22:21 ` Junio C Hamano
2009-11-25 22:31 ` A Large Angry SCM
2009-11-25 22:43 ` A Large Angry SCM
2009-11-25 23:34 ` Johannes Schindelin
2009-11-25 23:41 ` Junio C Hamano
2009-11-26 0:04 ` Johannes Schindelin
2009-11-26 0:13 ` Junio C Hamano
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=7v3a3x9kml.fsf@alter.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=jepicken@gmail.com \
--cc=peff@peff.net \
/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).