git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <peff@peff.net>
To: Felipe Contreras <felipe.contreras@gmail.com>
Cc: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>,
	Richard Hansen <rhansen@bbn.com>,
	git@vger.kernel.org, Andreas Krey <a.krey@gmx.de>,
	John Keeping <john@keeping.me.uk>,
	Philip Oakley <philipoakley@iee.org>,
	"brian m. carlson" <sandals@crustytoothpaste.net>
Subject: Re: [PATCH v3 1/5] pull: rename pull.rename to pull.mode
Date: Fri, 11 Oct 2013 21:25:15 -0400	[thread overview]
Message-ID: <20131012012515.GA1778@sigill.intra.peff.net> (raw)
In-Reply-To: <CAMP44s2y0UZ9uS8xtG2WDD=k5pHSG+K+_WM2dj-DVaUDy4djdA@mail.gmail.com>

On Fri, Oct 11, 2013 at 08:15:46PM -0500, Felipe Contreras wrote:

> >> You are free to go ahead and implement 'warning ()' in git-sh-setup.sh, in the
> >> meantime no shell script does that, and that's no reason to reject this patch
> >> series.
> >
> > You are completely missing Matthieu's point that we attempt to be
> > consistent in the format of messages, as well as where they are output,
> > and from a user's perspective it does not matter what language the tool
> > is implemented in.
> 
> If we truly did that, there should be a warning () function, like in C.

Or people could hand-code them to look similar, which is exactly what
has happened.

If you want to factor out a warning function to clean up the code, be my
guest. But the lack of one does not provide an argument that you should
break consistency.

> > -               echo "The configurations pull.rebase and branch.<name>.rebase are deprecated."
> > -               echo "Please use pull.mode and branch.<name>.pullmode instead."
> > +               echo >&2 "warning: The configurations pull.rebase and branch.<name>.rebase are deprecated."
> > +               echo >&2 "Please use pull.mode and branch.<name>.pullmode instead."
> [...]
> 
> Are you sure you want me to squash that in? Because the warnings
> wouldn't be consistent. Some would be "WARNING: " and others would be
> "warning: ". Personally I don't care, but if your argument is
> consistency, you should. If we had a warning () function, we could
> truly be consistent.

It is significant in the most important ways, which are labeling it at
all, and sending it to stderr. Capitalization is less important, in my
opinion.

Using a lowercase version is much more consistent with the warnings
produced by C code, which is why I chose it over the capitalized
version. Again, if you want to change the existing WARNING cases in the
shell scripts to be consistent with C output, be my guest.

Do you actually have some reason for wanting to output to go to stdout?

-Peff

  reply	other threads:[~2013-10-12  1:25 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-09  1:23 [PATCH v3 0/5] Preparation for non-ff pulls by default Felipe Contreras
2013-09-09  1:23 ` [PATCH v3 1/5] pull: rename pull.rename to pull.mode Felipe Contreras
2013-09-09 21:23   ` Richard Hansen
2013-09-09 22:49     ` Felipe Contreras
2013-09-10  2:21       ` Jeff King
2013-09-10  6:46         ` Felipe Contreras
2013-09-10  6:52           ` Jeff King
2013-09-10  8:16           ` Matthieu Moy
2013-10-11 23:56             ` Felipe Contreras
2013-10-12  0:32               ` Richard Hansen
2013-10-12  0:50               ` Jeff King
2013-10-12  1:15                 ` Felipe Contreras
2013-10-12  1:25                   ` Jeff King [this message]
2013-10-12  2:08                     ` Felipe Contreras
2013-10-12  4:40                       ` Richard Hansen
2013-10-12  6:21                         ` Felipe Contreras
2013-09-19 19:33       ` Richard Hansen
2013-10-11 23:54         ` Felipe Contreras
2013-09-10 21:34   ` Junio C Hamano
2013-09-09  1:23 ` [PATCH v3 2/5] pull: refactor $rebase variable into $mode Felipe Contreras
2013-09-09  1:23 ` [PATCH v3 3/5] pull: add --merge option Felipe Contreras
2013-09-09  1:23 ` [PATCH v3 4/5] pull: add merge-ff-only option Felipe Contreras
2013-09-09  1:23 ` [PATCH v3 5/5] pull: add warning on non-ff merges Felipe Contreras
2013-09-09  1:49   ` Felipe Contreras

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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=20131012012515.GA1778@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=Matthieu.Moy@grenoble-inp.fr \
    --cc=a.krey@gmx.de \
    --cc=felipe.contreras@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=john@keeping.me.uk \
    --cc=philipoakley@iee.org \
    --cc=rhansen@bbn.com \
    --cc=sandals@crustytoothpaste.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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).