Re: [PATCH] push: improve consistency of output when "up to date"

From: Patrick Steinhardt <ps@pks.im>
Date: Jan 15, 2024, 08:43 UTC
Message-ID: <ZaTwIUBKNhuAmrLX@tanuki>
In-Reply-To: <xmqqjzofec0e.fsf@gitster.g>

On Thu, Jan 11, 2024 at 02:33:21PM -0800, Junio C Hamano wrote:

Show 30 quoted lines

> Eric Sunshine <sunshine@sunshineco.com> writes:
> 
> > Thanks. This particular change is proposed periodically...
> >
> >> diff --git a/transport.c b/transport.c
> >> @@ -1467,7 +1467,7 @@ int transport_push(struct repository *r,
> >>         else if (!quiet && !ret && !transport_refs_pushed(remote_refs))
> >> -               fprintf(stderr, "Everything up-to-date\n");
> >> +               fprintf(stderr, "Everything up to date.\n");
> >
> > ... but has not been considered desirable.
> >
> > See, for instance, this email thread explaining the rationale for
> > avoiding such a change:
> > https://lore.kernel.org/git/pull.1298.git.1658908927714.gitgitgadget@gmail.com/T/
> 
> Looking at the "grep" hits:
> 
> $ git grep -e 'up-to-date.*"' \*.c
> builtin/rm.c:	OPT__FORCE(&force, N_("override the up-to-date check"), PARSE_OPT_NOCOMPLETE),
> builtin/send-pack.c:		fprintf(stderr, "Everything up-to-date\n");
> http-push.c:				fprintf(stderr, "'%s': up-to-date\n", ref->name);
> http-push.c:				      "Maybe you are not up-to-date and "
> transport.c:		fprintf(stderr, "Everything up-to-date\n");
> 
> it is true that these are not marked for translation, which should
> be a clue enough that we want them to be exactly the way they are
> spelled.  However, they are going to the standard error stream.  Is
> it reasonable to expect third-party tools scraping it to find the
> string "up-to-date"?

I would say it's not entirely reasonable:

  - These are strings that users see frequently, and if they are not
    proficient in the English language I think it actually regresses
    their user experience.

  - The way this string is written would never lead me, as a script
    developer, to think that this is a message that should be parsed by
    my script. It's simply too user-focussed to make me think so.

  - Last but not least, I think it's not entirely unreasonable to ask
    script developers to use e.g. LANG=C when they expect strings to be
    stable.

Also, with the introduction of `git push --porcelain`, I think there is even less reason to keep such user-visible strings intact. Any machine that wants to parse output of git-push(1) should use `--porcelain` instead in my opinion.

Patrick