From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS3215 2.6.0.0/16 X-Spam-Status: No, score=-2.4 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from out1.vger.email (out1.vger.email [IPv6:2620:137:e000::1:20]) by dcvr.yhbt.net (Postfix) with ESMTP id 654991F403 for ; Fri, 14 Oct 2022 08:57:48 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (1024-bit key; unprotected) header.d=klerks.biz header.i=@klerks.biz header.b="OuGKOIBL"; dkim-atps=neutral Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230022AbiJNI5r (ORCPT ); Fri, 14 Oct 2022 04:57:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36106 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230137AbiJNI5c (ORCPT ); Fri, 14 Oct 2022 04:57:32 -0400 Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E17A91C7118 for ; Fri, 14 Oct 2022 01:57:25 -0700 (PDT) Received: by mail-ed1-x533.google.com with SMTP id s2so5980854edd.2 for ; Fri, 14 Oct 2022 01:57:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klerks.biz; s=google; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=xWlFoSJOq0mRpKValMpXVkbjZK6ZZzvt6IKz+lH2a+I=; b=OuGKOIBL+tuB8XjQfVkcHG3SsPB20jre0wTNHMJIveXhd0SgliECZp9ZQG5uonzo0q Mr/paPEoZZvYPLkM70mZwOdlHzEuPjPw6ILLMWxLGsebqwNT7s710VVCEY3IJ4DQjM/O ZUkW1N9Ge3NNd4OeGU0DcslhearDRibyi0Ufw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=xWlFoSJOq0mRpKValMpXVkbjZK6ZZzvt6IKz+lH2a+I=; b=a08l7a48tNhpZmX/ZBCFYjdqaiK64BlXZ0sTHPJTj0NV3c6vkivS+o+dqgyOvZ73Jy MKpaNPNjzbAD1JbaR5vJrDV+feXR/xtZOzGpAjrUC2REWuVIpxHIJCGQVPlbwoKXS/ju Q7toxEDuezvxsUXch+1CBwX4XJ3Kxcy+EYCxobSsxRsxI/578kLUyRKFWpI4ZdceJ+Ln ivK7jWFQWwl9AKmDDi26y4tAZAof1d70GXvOEoD1E0gg5rJVRNHKzGnTcH5dra9/X6e9 3rnexyVU9Wc2qJujk+GCjtZcV10wT+kT+c/3L2ybalKl2nqOQHr1CNF5c/Bx/wITKlvj UoAQ== X-Gm-Message-State: ACrzQf0Y6avkL/Vy74lKYplsqWeJLoQ+IfbXsyNFiIklxUiMdcCq39jo bEu4ZrEY3pifItgTtlYM7EnfhhIPMEQOa65btyJZMOnlt+ORTsGe X-Google-Smtp-Source: AMsMyM4sEZihpKYJvRfw3V77KgYJvjMs6djLDcrxHY510We7i+hhF5zYlufPN3TAZ3aKl8TfNJLDK6nZUWO0L5oYam4= X-Received: by 2002:a05:6402:3454:b0:45c:a8b0:52d2 with SMTP id l20-20020a056402345400b0045ca8b052d2mr3478179edc.307.1665737843726; Fri, 14 Oct 2022 01:57:23 -0700 (PDT) MIME-Version: 1.0 References: <220930.86r0ztufwd.gmgdl@evledraar.gmail.com> In-Reply-To: From: Tao Klerks Date: Fri, 14 Oct 2022 10:57:11 +0200 Message-ID: Subject: Re: icase pathspec magic support in ls-tree To: Erik Cervin Edin Cc: Elijah Newren , "brian m. carlson" , =?UTF-8?B?w4Z2YXIgQXJuZmrDtnLDsCBCamFybWFzb24=?= , git Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org On Fri, Oct 14, 2022 at 10:04 AM Erik Cervin Edin wrote: > > > On Fri, Oct 14, 2022 at 6:59 AM Torsten B=C3=B6gershausen = wrote: > > > > For example, we can use Linux: > > git ls-files | tr 'A-Z' 'a-z' | sort | uniq -d ; echo $? > > In a repo with many files, maybe use git diff --name-only and just run > it periodically as a part of a check-in hook or something? > > git diff --name-only HEAD~100..HEAD | tr 'A-Z' 'a-z' | sort | uniq -d > > [... next email...] > I believe > git diff --name-only > doesn't need a working tree I don't understand this suggestion; doesn't it only catch duplicates where both instances were introduced in the same 100-commit range? That has often or typically not been the case, in my experience. Often one version of the file or folder will have existed for some time (days, months, years), and then a "duplicate" will be introduced. As far as I can tell this "diff large range" approach is quite expensive (37 seconds in a trivial test on this repo), and non-comprehensive.