On Tue, May 24, 2016 at 02:21:00PM -0700, Stefan Beller wrote:
> On Tue, May 24, 2016 at 1:51 PM, Yong Bakos <
[hidden email]> wrote:
> > Appending a period to "Everything up-to-date" makes the output message
> > consistent with similar output in builtin/merge.c.
> >
> > Signed-off-by: Yong Bakos <
[hidden email]>
> > ---
> > builtin/send-pack.c | 2 +-
> > transport.c | 2 +-
> > 2 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/builtin/send-pack.c b/builtin/send-pack.c
> > index 1ff5a67..67d9304 100644
> > --- a/builtin/send-pack.c
> > +++ b/builtin/send-pack.c
>
> While consistency is a good idea in general, I wonder how that applies here.
> git-send-pack is a low level (i.e. plumbing) command.
>
> The interface (input, output, set of options and the semantics) to
> these low-level commands are meant to be a lot more stable than
> Porcelain level commands, because these commands are primarily for
> scripted use. The interface to Porcelain commands on the other hand are
> subject to change in order to improve the end user experience.
>
> So if another porcelain exists and compares the output string
> exactly, this would be a regression for them. That is why I'd refrain
> from updating these strings
I think messages to stderr are generally fair game for changing, even in
plumbing. In many cases they are also translated (and I would argue that
these messages probably should be translated, too).
That being said, CodingGuidelines says:
- Do not end error messages with a full stop.
This isn't an error message exactly, but I think it's in the same vein.
I will note that we have not historically been consistent here, though
(as evidenced by the noted message in git-merge).
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
[hidden email]
More majordomo info at
http://vger.kernel.org/majordomo-info.html