From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeff King Subject: Re: Merge made by recursive? Date: Wed, 25 May 2011 17:02:54 -0400 Message-ID: <20110525210254.GA29716@sigill.intra.peff.net> References: <7vvcwy37de.fsf@alter.siamese.dyndns.org> <20110525195032.GC27260@sigill.intra.peff.net> <7vei3m3571.fsf@alter.siamese.dyndns.org> <7vzkma1p95.fsf@alter.siamese.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Cc: Shawn Ligocki , git@vger.kernel.org To: Junio C Hamano X-From: git-owner@vger.kernel.org Wed May 25 23:03:03 2011 Return-path: Envelope-to: gcvg-git-2@lo.gmane.org Received: from vger.kernel.org ([209.132.180.67]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QPLEM-0003QM-14 for gcvg-git-2@lo.gmane.org; Wed, 25 May 2011 23:03:02 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755144Ab1EYVC5 (ORCPT ); Wed, 25 May 2011 17:02:57 -0400 Received: from 99-108-226-0.lightspeed.iplsin.sbcglobal.net ([99.108.226.0]:54405 "EHLO peff.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753181Ab1EYVC4 (ORCPT ); Wed, 25 May 2011 17:02:56 -0400 Received: (qmail 5989 invoked by uid 107); 25 May 2011 21:02:56 -0000 Received: from sigill-wired.intra.peff.net (HELO sigill.intra.peff.net) (10.0.0.8) (smtp-auth username relayok, mechanism cram-md5) by peff.net (qpsmtpd/0.84) with ESMTPA; Wed, 25 May 2011 17:02:56 -0400 Received: by sigill.intra.peff.net (sSMTP sendmail emulation); Wed, 25 May 2011 17:02:54 -0400 Content-Disposition: inline In-Reply-To: <7vzkma1p95.fsf@alter.siamese.dyndns.org> Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: 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