From: Junio C Hamano <gitster@pobox.com>
To: Jakub Narebski <jnareb@gmail.com>
Cc: Heikki Orsila <heikki.orsila@iki.fi>, git@vger.kernel.org
Subject: Re: [PATCH] Start conforming code to "git subcmd" style
Date: Sun, 31 Aug 2008 09:14:43 -0700 [thread overview]
Message-ID: <7vk5dxb1qk.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <m38wudr0mq.fsf@localhost.localdomain> (Jakub Narebski's message of "Sun, 31 Aug 2008 02:32:05 -0700 (PDT)")
Jakub Narebski <jnareb@gmail.com> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> Heikki Orsila <heikki.orsila@iki.fi> writes:
>>
>> > User notifications are presented as 'git cmd', and code comments
>> > are presented as '"cmd"' or 'git's cmd', rather than 'git-cmd'.
> ...
>> > diff --git a/builtin-apply.c b/builtin-apply.c
>> > ...
>> > @@ -506,17 +506,17 @@ static char *gitdiff_verify_name(const char *li
>> > ...
>> > - die("git-apply: bad git-diff - expected /dev/nu...
>> > + die("git apply: bad git-diff - expected /dev/nu...
>> > ...
>>
>> I'd vote for doing "s/git-diff/patch/" here. After looking at
>> builtin-apply.c, there is no other error/die messages that would become
>> ambiguous, so such a rewording won't make it harder to help people who saw
>> any of these error messages (or other error messages from the "git-apply"
>> program).
>
> I agree. git-apply in general is presented a patch output, not
> necessary git-diff output (it could be output generated by GNU diff,
> or by 'scm diff' from some SCM...).
This codepath only is reached after we determine "diff --git" header, so
we are specifically expecting a patch intput with git flavor here. The
original wording of the message helps somebody who diagnoses at what point
in git-apply program the input is considered corrupt. My point was that
that line of thinking caters to a git programmer/debugger but changing it
to end user language (I suggested "patch", but I think "bad input" might
be even better) would not harm the debuggability this message is giving
us, because there is no similar message from the command from any other
codepath.
> I think that "git foo: message" is unambiguous, and I guess _that_
> could be even in one single large patch. Other cases I guess need
> careful review and thinking about in a case by case basis,
> unfortunately.
Yes, I think that is a very good suggestion. Thanks.
$ git grep -c -e '\(die\|error\|warning\)("git-[^ ]*:' 34baebc -- '*.c'
ho/dashless:builtin-apply.c:3
ho/dashless:builtin-checkout-index.c:3
ho/dashless:builtin-commit-tree.c:1
ho/dashless:builtin-fetch-pack.c:1
ho/dashless:builtin-grep.c:1
ho/dashless:builtin-ls-files.c:3
ho/dashless:builtin-rm.c:2
ho/dashless:builtin-show-ref.c:3
ho/dashless:builtin-tar-tree.c:2
ho/dashless:builtin-update-index.c:8
ho/dashless:connect.c:2
ho/dashless:entry.c:10
ho/dashless:merge-index.c:3
ho/dashless:tree-diff.c:1
ho/dashless:upload-pack.c:9
I've looked at the hits from the above command (without -c) and they all
looked good candidate, so I'll do that myself to reduce the amount of
patches that do need thinking and inspection.
next prev parent reply other threads:[~2008-08-31 16:16 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-30 11:12 [PATCH] Start conforming code to "git subcmd" style Heikki Orsila
2008-08-30 20:49 ` Junio C Hamano
2008-08-31 1:53 ` Christian Couder
2008-08-31 9:32 ` Jakub Narebski
2008-08-31 16:14 ` Junio C Hamano [this message]
2008-08-31 16:37 ` Heikki Orsila
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=7vk5dxb1qk.fsf@gitster.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=heikki.orsila@iki.fi \
--cc=jnareb@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).