All of lore.kernel.org
 help / color / mirror / Atom feed
From: Josh Soref <jsoref@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Josh Soref via GitGitGadget <gitgitgadget@gmail.com>,
	git@vger.kernel.org, Eric Sunshine <sunshine@sunshineco.com>
Subject: Re: [PATCH v3] git-merge: rewrite already up to date message
Date: Sat, 1 May 2021 21:51:29 -0400	[thread overview]
Message-ID: <CACZqfqCXrhUtsC3TLYaw6u7D0VohsBcz10aVxpe-1u8gg77qxQ@mail.gmail.com> (raw)
In-Reply-To: <xmqqk0ol7cka.fsf@gitster.g>

"Josh Soref via GitGitGadget" <gitgitgadget@gmail.com> writes:
> From: Josh Soref <jsoref@gmail.com>
> Co-authored-by: Eric Sunshine <sunshine@sunshineco.com>
> Signed-off-by: Josh Soref <jsoref@gmail.com>

Junio C Hamano <gitster@pobox.com> writes:
> I am not sure why this is Co-au, and not the more usual "Helped-by".

If you look at the thread, you'll see that the code in question was
written by Eric [1]. The only change from it was the addition of
`void` to the function prototype by me.

That said, it's my first foray into patches for git. I didn't use
helped-by because gitgitgadget didn't tell me to [2].

I have no opinion on the details. At this point, it's likely that a
second commit would include a helped-by referencing you. Maybe. I'm
not sure of the semantics of helped-by [2].

Junio C Hamano <gitster@pobox.com> wrote:
> Actually, not so fast.  The end-users do not care really where the
> message originates.
>
> $ git grep -e 'Already up[- ]to' \*.c
> maint:builtin/merge.c:          finish_up_to_date(_("Already up to date."));
> maint:builtin/merge.c:                  finish_up_to_date(_("Already up to date. Yeeah!"));
> maint:merge-ort-wrappers.c:             printf(_("Already up to date!"));
> maint:merge-recursive.c:                output(opt, 0, _("Already up to date!"));
> maint:notes-merge.c:                    printf("Already up to date!\n");
>
> It probably makes sense to replace the exclamation point with a full
> stop for others, no?

Maybe. I'm not sure what they mean.

I'm fully capable of wearing a grammar / UX hat and rewriting the
entire UX for a project if you invite me to do so.

I generally try not to do that when I initially approach a project, I
prefer to get more comfortable w/ it and let it get more comfortable
w/ me before I make significant change proposals.

(As an aside, I did start looking into what these messages meant /
what to change them to, but other things have come up, and I've
decided that I should at least respond to this message instead of just
appearing to disappear.)

> Also, I didn't notice when reading the patch submission earlier, but
> what does
>
> >> (All localizations of the previous strings are broken.)
>
> mean, exactly?  Do you mean to say
>
>     Because this changes some messages, the old messages that were
>     already translated will no longer be used, and these new
>     messages need to be translated anew.

Yes, this is what I meant. It's probably technically obvious to some
people, but since I'm invited to describe the effects of my change, it
seemed worth noting. Anyone cutting a release with this commit but not
updating the translations would be bleeding en-US into the
translations where before they would have had translated content.
(Whether that translated content was any good given the fact that it
was pasted together is a different story, but...)

[1] https://lore.kernel.org/git/CAPig+cT=xeLn9KNHz7hiNWo0QTfc1zZ1X-czJ4n503RRhBA0XQ@mail.gmail.com/
[2] https://github.com/gitgitgadget/gitgitgadget/issues/543

  reply	other threads:[~2021-05-02  1:51 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-18 18:33 [PATCH] git-merge: move space to between strings Josh Soref via GitGitGadget
2021-04-18 19:17 ` Junio C Hamano
2021-04-21 23:22 ` [PATCH v2] git-merge: move primary point before parenthetical Josh Soref via GitGitGadget
2021-04-21 23:46   ` Eric Sunshine
2021-04-22  0:55   ` [PATCH v3] git-merge: rewrite already up to date message Josh Soref via GitGitGadget
2021-04-22  3:41     ` Eric Sunshine
2021-04-28  4:04     ` Junio C Hamano
2021-04-29  7:52       ` Junio C Hamano
2021-05-02  1:51         ` Josh Soref [this message]
2021-05-02  2:15           ` Eric Sunshine
2021-05-02  2:39             ` Junio C Hamano
2021-05-02  6:26             ` Junio C Hamano
2021-05-02  7:14               ` Eric Sunshine
2021-05-02  5:14     ` [PATCH v4 0/2] normalize & fix merge "up to date" messages Eric Sunshine
2021-05-02  5:14       ` [PATCH v4 1/2] merge(s): apply consistent punctuation to " Eric Sunshine
2021-05-02  5:14       ` [PATCH v4 2/2] merge: fix swapped "up to date" message components Eric Sunshine
2021-05-03  5:21         ` Junio C Hamano
2021-05-03  5:50           ` Eric Sunshine
2021-05-03  6:28             ` Junio C Hamano

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

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

  git send-email \
    --in-reply-to=CACZqfqCXrhUtsC3TLYaw6u7D0VohsBcz10aVxpe-1u8gg77qxQ@mail.gmail.com \
    --to=jsoref@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=gitster@pobox.com \
    --cc=sunshine@sunshineco.com \
    /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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.