push: improve consistency of output when "up to date" #1638
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Welcome to GitGitGadgetHi @okaybenji, and welcome to GitGitGadget, the GitHub App to send patch series to the Git mailing list from GitHub Pull Requests. Please make sure that your Pull Request has a good description, as it will be used as cover letter. You can CC potential reviewers by adding a footer to the PR description with the following syntax: Also, it is a good idea to review the commit messages one last time, as the Git project expects them in a quite specific form:
It is in general a good idea to await the automated test ("Checks") in this Pull Request before contributing the patches, e.g. to avoid trivial issues such as unportable code. Contributing the patchesBefore you can contribute the patches, your GitHub username needs to be added to the list of permitted users. Any already-permitted user can do that, by adding a comment to your PR of the form Both the person who commented An alternative is the channel Once on the list of permitted usernames, you can contribute the patches to the Git mailing list by adding a PR comment If you want to see what email(s) would be sent for a After you submit, GitGitGadget will respond with another comment that contains the link to the cover letter mail in the Git mailing list archive. Please make sure to monitor the discussion in that thread and to address comments and suggestions (while the comments and suggestions will be mirrored into the PR by GitGitGadget, you will still want to reply via mail). If you do not want to subscribe to the Git mailing list just to be able to respond to a mail, you can download the mbox from the Git mailing list archive (click the curl -g --user "<EMailAddress>:<Password>" \
--url "imaps://imap.gmail.com/INBOX" -T /path/to/raw.txtTo iterate on your change, i.e. send a revised patch or patch series, you will first want to (force-)push to the same branch. You probably also want to modify your Pull Request description (or title). It is a good idea to summarize the revision by adding something like this to the cover letter (read: by editing the first comment on the PR, i.e. the PR description): To send a new iteration, just add another PR comment with the contents: Need help?New contributors who want advice are encouraged to join git-mentoring@googlegroups.com, where volunteers who regularly contribute to Git are willing to answer newbie questions, give advice, or otherwise provide mentoring to interested contributors. You must join in order to post or view messages, but anyone can join. You may also be able to find help in real time in the developer IRC channel, |
|
There are issues in commit 62cfe0d: |
|
There are issues in commit acc2158: |
|
/allow |
|
User okaybenji is now allowed to use GitGitGadget. WARNING: okaybenji has no public email address set on GitHub; |
When one issues the pull command, one may see "Already up to date." When issuing the push command, one may have seen "Everything up-to-date". To improve consistency, "Everything up to date." is printed instead. (The hyphens have been removed, and a period has been added.) Signed-off-by: okaybenji <okaybenji@gmail.com>
|
/preview |
|
Preview email sent as pull.1638.git.1705008185014.gitgitgadget@gmail.com |
|
/submit |
|
Submitted as pull.1638.git.1705008449995.gitgitgadget@gmail.com To fetch this version into To fetch this version to local tag |
|
On the Git mailing list, Eric Sunshine wrote (reply to this): On Thu, Jan 11, 2024 at 4:27 PM Benji Kay via GitGitGadget
<gitgitgadget@gmail.com> wrote:
> When one issues the pull command, one may see "Already up to date."
> When issuing the push command, one may have seen "Everything up-to-date".
> To improve consistency, "Everything up to date." is printed instead.
> (The hyphens have been removed, and a period has been added.)
>
> Signed-off-by: okaybenji <okaybenji@gmail.com>
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/ |
|
User |
|
On the Git mailing list, Taylor Blau wrote (reply to this): On Thu, Jan 11, 2024 at 09:27:29PM +0000, Benji Kay via GitGitGadget wrote:
> From: okaybenji <okaybenji@gmail.com>
>
> When one issues the pull command, one may see "Already up to date."
> When issuing the push command, one may have seen "Everything up-to-date".
> To improve consistency, "Everything up to date." is printed instead.
> (The hyphens have been removed, and a period has been added.)
>
> Signed-off-by: okaybenji <okaybenji@gmail.com>
> ---
> push: improve consistency of output when "up to date"
>
> Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-1638%2Fokaybenji%2Fup-to-date-v1
> Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1638/okaybenji/up-to-date-v1
> Pull-Request: https://github.com/gitgitgadget/git/pull/1638
>
> transport.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/transport.c b/transport.c
> index bd7899e9bf5..c42cb4e58b4 100644
> --- a/transport.c
> +++ b/transport.c
> @@ -1467,7 +1467,7 @@ int transport_push(struct repository *r,
> if (porcelain && !push_ret)
> puts("Done");
> else if (!quiet && !ret && !transport_refs_pushed(remote_refs))
> - fprintf(stderr, "Everything up-to-date\n");
> + fprintf(stderr, "Everything up to date.\n");
Between the two, I have a vague preference towards "up-to-date", which
would suggest changing the pull command's output to read "Already
up-to-date". Personally I think that neither of them should include a
period in their output, but whichever we decide should be done so
consistently between the two.
Also, should this string be marked for translation?
Thanks,
Taylor |
|
User |
|
On the Git mailing list, Eric Sunshine wrote (reply to this): On Thu, Jan 11, 2024 at 4:44 PM Taylor Blau <me@ttaylorr.com> wrote:
> On Thu, Jan 11, 2024 at 09:27:29PM +0000, Benji Kay via GitGitGadget wrote:
> > - fprintf(stderr, "Everything up-to-date\n");
> > + fprintf(stderr, "Everything up to date.\n");
>
> Between the two, I have a vague preference towards "up-to-date", which
> would suggest changing the pull command's output to read "Already
> up-to-date". Personally I think that neither of them should include a
> period in their output, but whichever we decide should be done so
> consistently between the two.
>
> Also, should this string be marked for translation?
See: https://lore.kernel.org/git/7n9r5q74-9qr1-29sr-p2n5-943n01s0p78r@tzk.qr/ |
|
On the Git mailing list, Junio C Hamano wrote (reply to this): 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"?
In any case, a safe first step is to add a short comment to each of
these that should not be translated. Perhaps something along this
line.
------- >8 ------------- >8 ------------- >8 -------
Subject: [PATCH] messages: mark some strings with "up-to-date" not to touch
The treewide clean-up of "up-to-date" strings done in 7560f547
(treewide: correct several "up-to-date" to "up to date", 2017-08-23)
deliberately left some out, but unlike the lines that were changed
by the commit, the lines that were deliberately left untouched by
the commit is impossible to ask "git blame" to link back to the
commit that did not touch them.
Let's do the second best thing, leave a short comment near them, to
make it possible for those who are motivated enough to find out why
we decided to tell them "do not modify".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin/send-pack.c | 1 +
http-push.c | 2 ++
transport.c | 1 +
3 files changed, 4 insertions(+)
diff --git a/builtin/send-pack.c b/builtin/send-pack.c
index b7183be970..ac7ec1e643 100644
--- a/builtin/send-pack.c
+++ b/builtin/send-pack.c
@@ -333,6 +333,7 @@ int cmd_send_pack(int argc, const char **argv, const char *prefix)
}
if (!ret && !transport_refs_pushed(remote_refs))
+ /* do not modify this string */
fprintf(stderr, "Everything up-to-date\n");
return ret;
diff --git a/http-push.c b/http-push.c
index b4d0b2a6aa..e4c6645cc2 100644
--- a/http-push.c
+++ b/http-push.c
@@ -1851,6 +1851,7 @@ int cmd_main(int argc, const char **argv)
if (oideq(&ref->old_oid, &ref->peer_ref->new_oid)) {
if (push_verbosely)
+ /* do not modify this string */
fprintf(stderr, "'%s': up-to-date\n", ref->name);
if (helper_status)
printf("ok %s up to date\n", ref->name);
@@ -1871,6 +1872,7 @@ int cmd_main(int argc, const char **argv)
* commits at the remote end and likely
* we were not up to date to begin with.
*/
+ /* do not modify this string */
error("remote '%s' is not an ancestor of\n"
"local '%s'.\n"
"Maybe you are not up-to-date and "
diff --git a/transport.c b/transport.c
index bd7899e9bf..c9f39d45f1 100644
--- a/transport.c
+++ b/transport.c
@@ -1467,6 +1467,7 @@ int transport_push(struct repository *r,
if (porcelain && !push_ret)
puts("Done");
else if (!quiet && !ret && !transport_refs_pushed(remote_refs))
+ /* do not modify this string */
fprintf(stderr, "Everything up-to-date\n");
done:
--
2.43.0-283-ga54a84b333
|
|
On the Git mailing list, Benji Kay wrote (reply to this): If it's important these messages are not changed (under the presumption
some programs may make decisions based on the output), perhaps a test
should be written to ensure the output is as expected. |
|
User |
|
On the Git mailing list, Eric Sunshine wrote (reply to this): On Thu, Jan 11, 2024 at 5:33 PM Junio C Hamano <gitster@pobox.com> wrote:
> Eric Sunshine <sunshine@sunshineco.com> writes:
> > Thanks. This particular change is proposed periodically...
> > ... 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/
>
> Let's do the second best thing, leave a short comment near them, to
> make it possible for those who are motivated enough to find out why
> we decided to tell them "do not modify".
> ---
> diff --git a/builtin/send-pack.c b/builtin/send-pack.c
> @@ -333,6 +333,7 @@ int cmd_send_pack(int argc, const char **argv, const char *prefix)
> if (!ret && !transport_refs_pushed(remote_refs))
> + /* do not modify this string */
> fprintf(stderr, "Everything up-to-date\n");
Yes, that helps, though, we can probably be a bit more friendly to
future developers. Rather than insisting that they dig through
history, we could use a slightly less terse comment, such as:
/* stable plumbing output; do not modify or localize */ |
|
On the Git mailing list, Eric Sunshine wrote (reply to this): From: Junio C Hamano <gitster@pobox.com>
The treewide clean-up of "up-to-date" strings done in 7560f547
(treewide: correct several "up-to-date" to "up to date", 2017-08-23)
deliberately left some out, but unlike the lines that were changed
by the commit, the lines that were deliberately left untouched by
the commit is impossible to ask "git blame" to link back to the
commit that did not touch them.
Let's do the second best thing, leave a short comment near them
explaining why those strings should not be modified or localized.
[es: make in-code comment more developer-friendly]
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
---
This is a reroll of Junio's[1] v1 which adds an in-code comment
explaining that "up-to-date" messages in plumbing commands should not be
changed, but doesn't explain _why_, which forces readers to dig through
project history or the mailing list to understand the motivation. v2
changes the comment to be more developer-friendly by adding the
explanation directly to the comment.
[1]: https://lore.kernel.org/git/xmqqjzofec0e.fsf@gitster.g/
Range-diff:
1: 36596051c9 ! 1: 782169e0b1 messages: mark some strings with "up-to-date" not to touch
@@ Commit message
the commit is impossible to ask "git blame" to link back to the
commit that did not touch them.
- Let's do the second best thing, leave a short comment near them, to
- make it possible for those who are motivated enough to find out why
- we decided to tell them "do not modify".
+ Let's do the second best thing, leave a short comment near them
+ explaining why those strings should not be modified or localized.
+
+ [es: make in-code comment more developer-friendly]
Signed-off-by: Junio C Hamano <gitster@pobox.com>
+ Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
## builtin/send-pack.c ##
@@ builtin/send-pack.c: int cmd_send_pack(int argc, const char **argv, const char *prefix)
}
if (!ret && !transport_refs_pushed(remote_refs))
-+ /* do not modify this string */
++ /* stable plumbing output; do not modify or localize */
fprintf(stderr, "Everything up-to-date\n");
return ret;
@@ http-push.c: int cmd_main(int argc, const char **argv)
if (oideq(&ref->old_oid, &ref->peer_ref->new_oid)) {
if (push_verbosely)
-+ /* do not modify this string */
++ /* stable plumbing output; do not modify or localize */
fprintf(stderr, "'%s': up-to-date\n", ref->name);
if (helper_status)
printf("ok %s up to date\n", ref->name);
@@ http-push.c: int cmd_main(int argc, const char **argv)
* commits at the remote end and likely
* we were not up to date to begin with.
*/
-+ /* do not modify this string */
++ /* stable plumbing output; do not modify or localize */
error("remote '%s' is not an ancestor of\n"
"local '%s'.\n"
"Maybe you are not up-to-date and "
@@ transport.c: int transport_push(struct repository *r,
if (porcelain && !push_ret)
puts("Done");
else if (!quiet && !ret && !transport_refs_pushed(remote_refs))
-+ /* do not modify this string */
++ /* stable plumbing output; do not modify or localize */
fprintf(stderr, "Everything up-to-date\n");
done:
builtin/send-pack.c | 1 +
http-push.c | 2 ++
transport.c | 1 +
3 files changed, 4 insertions(+)
diff --git a/builtin/send-pack.c b/builtin/send-pack.c
index b7183be970..3df9eaad09 100644
--- a/builtin/send-pack.c
+++ b/builtin/send-pack.c
@@ -333,6 +333,7 @@ int cmd_send_pack(int argc, const char **argv, const char *prefix)
}
if (!ret && !transport_refs_pushed(remote_refs))
+ /* stable plumbing output; do not modify or localize */
fprintf(stderr, "Everything up-to-date\n");
return ret;
diff --git a/http-push.c b/http-push.c
index b4d0b2a6aa..12d1113741 100644
--- a/http-push.c
+++ b/http-push.c
@@ -1851,6 +1851,7 @@ int cmd_main(int argc, const char **argv)
if (oideq(&ref->old_oid, &ref->peer_ref->new_oid)) {
if (push_verbosely)
+ /* stable plumbing output; do not modify or localize */
fprintf(stderr, "'%s': up-to-date\n", ref->name);
if (helper_status)
printf("ok %s up to date\n", ref->name);
@@ -1871,6 +1872,7 @@ int cmd_main(int argc, const char **argv)
* commits at the remote end and likely
* we were not up to date to begin with.
*/
+ /* stable plumbing output; do not modify or localize */
error("remote '%s' is not an ancestor of\n"
"local '%s'.\n"
"Maybe you are not up-to-date and "
diff --git a/transport.c b/transport.c
index bd7899e9bf..df518ead70 100644
--- a/transport.c
+++ b/transport.c
@@ -1467,6 +1467,7 @@ int transport_push(struct repository *r,
if (porcelain && !push_ret)
puts("Done");
else if (!quiet && !ret && !transport_refs_pushed(remote_refs))
+ /* stable plumbing output; do not modify or localize */
fprintf(stderr, "Everything up-to-date\n");
done:
--
2.43.0
|
|
User |
|
On the Git mailing list, Junio C Hamano wrote (reply to this): Eric Sunshine <ericsunshine@charter.net> writes:
> Let's do the second best thing, leave a short comment near them
> explaining why those strings should not be modified or localized.
I simply could not come up with a short and concise in-code comment
;-) What you picked looks good to me.
Thanks.
>
> [es: make in-code comment more developer-friendly]
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
> ---
>
> This is a reroll of Junio's[1] v1 which adds an in-code comment
> explaining that "up-to-date" messages in plumbing commands should not be
> changed, but doesn't explain _why_, which forces readers to dig through
> project history or the mailing list to understand the motivation. v2
> changes the comment to be more developer-friendly by adding the
> explanation directly to the comment.
>
> [1]: https://lore.kernel.org/git/xmqqjzofec0e.fsf@gitster.g/
>
> Range-diff:
> 1: 36596051c9 ! 1: 782169e0b1 messages: mark some strings with "up-to-date" not to touch
> @@ Commit message
> the commit is impossible to ask "git blame" to link back to the
> commit that did not touch them.
>
> - Let's do the second best thing, leave a short comment near them, to
> - make it possible for those who are motivated enough to find out why
> - we decided to tell them "do not modify".
> + Let's do the second best thing, leave a short comment near them
> + explaining why those strings should not be modified or localized.
> +
> + [es: make in-code comment more developer-friendly]
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> + Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
>
> ## builtin/send-pack.c ##
> @@ builtin/send-pack.c: int cmd_send_pack(int argc, const char **argv, const char *prefix)
> }
>
> if (!ret && !transport_refs_pushed(remote_refs))
> -+ /* do not modify this string */
> ++ /* stable plumbing output; do not modify or localize */
> fprintf(stderr, "Everything up-to-date\n");
>
> return ret;
> @@ http-push.c: int cmd_main(int argc, const char **argv)
>
> if (oideq(&ref->old_oid, &ref->peer_ref->new_oid)) {
> if (push_verbosely)
> -+ /* do not modify this string */
> ++ /* stable plumbing output; do not modify or localize */
> fprintf(stderr, "'%s': up-to-date\n", ref->name);
> if (helper_status)
> printf("ok %s up to date\n", ref->name);
> @@ http-push.c: int cmd_main(int argc, const char **argv)
> * commits at the remote end and likely
> * we were not up to date to begin with.
> */
> -+ /* do not modify this string */
> ++ /* stable plumbing output; do not modify or localize */
> error("remote '%s' is not an ancestor of\n"
> "local '%s'.\n"
> "Maybe you are not up-to-date and "
> @@ transport.c: int transport_push(struct repository *r,
> if (porcelain && !push_ret)
> puts("Done");
> else if (!quiet && !ret && !transport_refs_pushed(remote_refs))
> -+ /* do not modify this string */
> ++ /* stable plumbing output; do not modify or localize */
> fprintf(stderr, "Everything up-to-date\n");
>
> done:
>
> builtin/send-pack.c | 1 +
> http-push.c | 2 ++
> transport.c | 1 +
> 3 files changed, 4 insertions(+)
>
> diff --git a/builtin/send-pack.c b/builtin/send-pack.c
> index b7183be970..3df9eaad09 100644
> --- a/builtin/send-pack.c
> +++ b/builtin/send-pack.c
> @@ -333,6 +333,7 @@ int cmd_send_pack(int argc, const char **argv, const char *prefix)
> }
>
> if (!ret && !transport_refs_pushed(remote_refs))
> + /* stable plumbing output; do not modify or localize */
> fprintf(stderr, "Everything up-to-date\n");
>
> return ret;
> diff --git a/http-push.c b/http-push.c
> index b4d0b2a6aa..12d1113741 100644
> --- a/http-push.c
> +++ b/http-push.c
> @@ -1851,6 +1851,7 @@ int cmd_main(int argc, const char **argv)
>
> if (oideq(&ref->old_oid, &ref->peer_ref->new_oid)) {
> if (push_verbosely)
> + /* stable plumbing output; do not modify or localize */
> fprintf(stderr, "'%s': up-to-date\n", ref->name);
> if (helper_status)
> printf("ok %s up to date\n", ref->name);
> @@ -1871,6 +1872,7 @@ int cmd_main(int argc, const char **argv)
> * commits at the remote end and likely
> * we were not up to date to begin with.
> */
> + /* stable plumbing output; do not modify or localize */
> error("remote '%s' is not an ancestor of\n"
> "local '%s'.\n"
> "Maybe you are not up-to-date and "
> diff --git a/transport.c b/transport.c
> index bd7899e9bf..df518ead70 100644
> --- a/transport.c
> +++ b/transport.c
> @@ -1467,6 +1467,7 @@ int transport_push(struct repository *r,
> if (porcelain && !push_ret)
> puts("Done");
> else if (!quiet && !ret && !transport_refs_pushed(remote_refs))
> + /* stable plumbing output; do not modify or localize */
> fprintf(stderr, "Everything up-to-date\n");
>
> done: |
|
On the Git mailing list, Patrick Steinhardt wrote (reply to this): On Thu, Jan 11, 2024 at 02:33:21PM -0800, Junio C Hamano wrote:
> 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 |
|
User |
|
On the Git mailing list, Dragan Simic wrote (reply to this): On 2024-01-11 22:43, Taylor Blau wrote:
> On Thu, Jan 11, 2024 at 09:27:29PM +0000, Benji Kay via GitGitGadget > wrote:
>> From: okaybenji <okaybenji@gmail.com>
>> >> When one issues the pull command, one may see "Already up to date."
>> When issuing the push command, one may have seen "Everything >> up-to-date".
>> To improve consistency, "Everything up to date." is printed instead.
>> (The hyphens have been removed, and a period has been added.)
>> >> Signed-off-by: okaybenji <okaybenji@gmail.com>
>> ---
>> push: improve consistency of output when "up to date"
>> >> Published-As: >> https://github.com/gitgitgadget/git/releases/tag/pr-1638%2Fokaybenji%2Fup-to-date-v1
>> Fetch-It-Via: git fetch https://github.com/gitgitgadget/git >> pr-1638/okaybenji/up-to-date-v1
>> Pull-Request: https://github.com/gitgitgadget/git/pull/1638
>> >> transport.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>> >> diff --git a/transport.c b/transport.c
>> index bd7899e9bf5..c42cb4e58b4 100644
>> --- a/transport.c
>> +++ b/transport.c
>> @@ -1467,7 +1467,7 @@ int transport_push(struct repository *r,
>> if (porcelain && !push_ret)
>> puts("Done");
>> else if (!quiet && !ret && !transport_refs_pushed(remote_refs))
>> - fprintf(stderr, "Everything up-to-date\n");
>> + fprintf(stderr, "Everything up to date.\n");
> > Between the two, I have a vague preference towards "up-to-date", which
> would suggest changing the pull command's output to read "Already
> up-to-date". Personally I think that neither of them should include a
> period in their output, but whichever we decide should be done so
> consistently between the two.
I'm not a native English speaker, but I spent years contributing to English Wikipedia. According to the manual of style employed by Wikipedia, which is based mainly on The Chicago Manual of Style, hyphenated forms should not be used at the ends of sentences, or at the ends of sentence-like forms. In this case, we don't have complete sentences.
[1] https://www.chicagomanualofstyle.org/home.html |
|
User |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
cc: Eric Sunshine sunshine@sunshineco.com
cc: Taylor Blau me@ttaylorr.com
cc: Benji Kay okaybenji@gmail.com
cc: Eric Sunshine ericsunshine@charter.net
cc: Patrick Steinhardt ps@pks.im
cc: Dragan Simic dsimic@manjaro.org