On Tue, May 24, 2016 at 02:21:00PM -0700, Stefan Beller wrote: > On Tue, May 24, 2016 at 1:51 PM, Yong Bakos <j...@humanoriented.com> 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 <yba...@humanoriented.com> > > --- > > 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
