From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-3.5 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_HI,RCVD_IN_SORBS_SPAM, RP_MATCHES_RCVD shortcircuit=no autolearn=ham autolearn_force=no version=3.4.0 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by dcvr.yhbt.net (Postfix) with ESMTP id 5E795209AE for ; Thu, 13 Oct 2016 05:13:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755076AbcJMFNf (ORCPT ); Thu, 13 Oct 2016 01:13:35 -0400 Received: from mail-pf0-f194.google.com ([209.85.192.194]:35475 "EHLO mail-pf0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754944AbcJMFNd (ORCPT ); Thu, 13 Oct 2016 01:13:33 -0400 Received: by mail-pf0-f194.google.com with SMTP id s8so4220314pfj.2 for ; Wed, 12 Oct 2016 22:13:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=DH8Cck5d1vFYZNQumwikkUpgMgldin0o+fw5YKFf72M=; b=InY7+sjG/hs76wKNLFZZsRkdaTytsnizVRHL8OBVk8JPe2REsysdd/7mY1Sacw4tSY FXm+y1OurdWsccKN5ZRi4LRN8hJLKpRUfDr1rEc5NoCrAEnaGCeZlfhX+BUg62mKLc+a +MUGtno7jMacKvyK1U4WJr9TwK/KxQzcHOpySTlCBCi/WklbKbrcuYU8/eIG9GgwPkRE sS+p6Ap43GVnEW+hEDOSd+EVu5vbx46B2nVdbihH4oT4jEi8OJoSwP1tpmPKMETH8uDr FIEwCOW8tMgZz4YyfT1bRTOH2u0Ro0MdYBWvLV5GFrdJkOMB8wwJilZYwvR9aWLo29w7 Zapw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=DH8Cck5d1vFYZNQumwikkUpgMgldin0o+fw5YKFf72M=; b=OZ37z+FxC/3nBocKfT5V2ahah3w7Mlya3EhQhTDbmj/zKWklGcPRbKXynRimWKsu6c PAwfCCH68FePkEagVa83QKK1kz0ZTGgqIm0Ik3YMLY2J24OldkxBBUIQRT3DeFcWXL5J ZXHEWd1r5o4dGJd83dfEuPCZhZWMa0+oOxps3qcTU48kA269S0O67XdA+aFh0a7dybMy zXUtZq4EbwV7XymL7ACc9xvdaV5AwCkSWC40nFpOHOdDiaF62dXdrykwbdzXCg2GggYT 8eqpyGqCSvrHenONfm0yg/J+VlE4LGLhvvgIrI7Jzph3BYEWEEcDcPhkmvt81L8/Gn4v fJdA== X-Gm-Message-State: AA6/9RlrT+RiJKUJ0U7eLc4Pt5Vkm7j+Smt+nUYCLm8DN3WxxP/norzmM/7CxPIF/mBDvw== X-Received: by 10.99.0.204 with SMTP id 195mr5941463pga.78.1476335612792; Wed, 12 Oct 2016 22:13:32 -0700 (PDT) Received: from gmail.com (208-106-56-2.static.sonic.net. [208.106.56.2]) by smtp.gmail.com with ESMTPSA id a4sm15737535pax.8.2016.10.12.22.13.31 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 12 Oct 2016 22:13:31 -0700 (PDT) Date: Wed, 12 Oct 2016 22:13:29 -0700 From: David Aguilar To: Josef Ridky Cc: git@vger.kernel.org Subject: Re: [PATCH 1/2] Feature Request: user defined suffix for temp files created by git-mergetool Message-ID: <20161013051329.GA26538@gmail.com> References: <1329039097.128066.1475476591437.JavaMail.zimbra@redhat.com> <1499287628.1324571.1475653631366.JavaMail.zimbra@redhat.com> <1214659824.1976049.1475738509473.JavaMail.zimbra@redhat.com> <1911899288.2172724.1475757782111.JavaMail.zimbra@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1911899288.2172724.1475757782111.JavaMail.zimbra@redhat.com> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org On Thu, Oct 06, 2016 at 08:43:02AM -0400, Josef Ridky wrote: > This is the first of two variant for request to add option to change > suffix of name of temporary files generated by git mergetool. This > change is requested for cases, when is git mergetool used for local > comparision between two version of same package during package rebase. > > Signed-off-by: Josef Ridky > --- > Documentation/git-mergetool.txt | 7 ++++++- > git-mergetool.sh | 23 ++++++++++++++++++----- > 2 files changed, 24 insertions(+), 6 deletions(-) While I do like that this variant only uses a single flag, I was curious whether it would make sense for us to change our defaults to OLD/NEW? I'm thinking "no" since it's totally legit to merge "old" branches so I'll stop there. What I really wanted to mention was... If the patch does not update t/t7610-mergetool.sh then there is no guarantee that my clumsy fingers won't break the new feature in the future ;-) So please make sure to update the tests once we decide on the final direction. It makes sense we wouldn't want to update them just yet (in this patch) since this is still RFC, but the final one should include it. I'm still leaning towards environment variables personally, and would have no qualms against taking a patch that teaches it to support environment variables as long as it adds a test case for the new feature. Thanks for sticking with it, Josef! cheers, -- David