Re: Merge made by recursive?

[Jeff King <peff@peff.net>]

On Wed, May 25, 2011 at 01:47:34PM -0700, Junio C Hamano wrote:

> I am reluctant to do this (including the rewording of the end-user facing
> message) until we decide what to do with the reflog. Right now, I think no
> tool looks at the reflog, but contaminating the reflog with translatable
> messages mean that we will never be able to support "3 merges ago" just
> like we support "the previous branch".

The reflog messages look like:

  merge $branch: Merge made by recursive.

So it seems to me that we could localize everything after the colon and
still do "3 merges ago". The only thing you would be losing is a
machine-readable description of which strategy was used. In practice,
I'm not sure how much it matters.

But for others, like:

  checkout: moving from $old to $new

a localized version loses useful information.

> Either we split the messages into two, one translatable and given to the
> end user and the other untranslatable and sent to the reflog,

That seems like the safe choice for now, as it still opens the
possibility of localizing reflogs later if people care to do so.  Being
a native English speaker, I have no clue how much people actually care
about localized reflog entries.

> place in reflog entry where we can hide machine readable and stable
> representation of what happened and store both the end-user facing message
> and the machine readable one separately. In the longer term I would prefer
> the latter.

If we assume that reflog entries are machine-readable (or at least
_some_ of them that are generated by a few well-known git programs), you
could always translate on the fly while displaying them.

That solves the storage question, and it allows two people with
different language preferences to both read the same reflog. And the
implementation probably wouldn't be too hard, since we'd only have to
match a few well-known strings, and we could display anything we didn't
match as it appears in the reflog.

-Peff