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: AS53758 23.128.96.0/24 X-Spam-Status: No, score=-3.9 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by dcvr.yhbt.net (Postfix) with ESMTP id DDFFD1F8C6 for ; Thu, 1 Jul 2021 17:42:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233128AbhGARpP (ORCPT ); Thu, 1 Jul 2021 13:45:15 -0400 Received: from pb-smtp20.pobox.com ([173.228.157.52]:59613 "EHLO pb-smtp20.pobox.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229978AbhGARpO (ORCPT ); Thu, 1 Jul 2021 13:45:14 -0400 Received: from pb-smtp20.pobox.com (unknown [127.0.0.1]) by pb-smtp20.pobox.com (Postfix) with ESMTP id E20B2139E80; Thu, 1 Jul 2021 13:42:43 -0400 (EDT) (envelope-from junio@pobox.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=sasl; bh=INMKXrJGHV3qye/Rmym1481NKXEjeUwJNZmI2a JEbX0=; b=ZM6fJ4EHRSNPr93OwPeFDRyn53O9pAALbjZY8xonuKvhXqGxzmjRxW o26N98wjqfpzlNQvGjMRDIdjqpeqVWLIfYdckg7M/gxyb82UC/sTXNZULPSf6LPm 3Cd/1uB+8EA8Zn0C13MkenYLZV8PrdfVDijOpJRHFRT+HBLvi4TAM= Received: from pb-smtp20.sea.icgroup.com (unknown [127.0.0.1]) by pb-smtp20.pobox.com (Postfix) with ESMTP id DA765139E7F; Thu, 1 Jul 2021 13:42:43 -0400 (EDT) (envelope-from junio@pobox.com) Received: from pobox.com (unknown [34.74.3.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pb-smtp20.pobox.com (Postfix) with ESMTPSA id 31056139E7E; Thu, 1 Jul 2021 13:42:41 -0400 (EDT) (envelope-from junio@pobox.com) From: Junio C Hamano To: "Johannes Schindelin via GitGitGadget" Cc: git@vger.kernel.org, Ramsay Jones , Duy Nguyen , Johannes Sixt , Jeff King , Eric Sunshine , Johannes Schindelin Subject: Re: [PATCH v2 0/2] mingw: handle absolute paths in expand_user_path() References: Date: Thu, 01 Jul 2021 10:42:39 -0700 In-Reply-To: (Johannes Schindelin via GitGitGadget's message of "Thu, 01 Jul 2021 16:03:05 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Pobox-Relay-ID: BBE2A88A-DA93-11EB-946D-D5C30F5B5667-77302942!pb-smtp20.pobox.com Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org "Johannes Schindelin via GitGitGadget" writes: > In Git for Windows, we ran with a patch "in production" for quite a while > where paths starting with a slash (i.e. looking like Unix paths, not like > Windows paths) were interpreted as being relative to the runtime prefix, > when expanded via expand_user_path(). > > This was sent to the Git mailing list as a discussion starter, and it was > pointed out that this is neither portable nor unambiguous. > > After the dust settled, I thought about the presented ideas for a while > (quite a while...), and ended up with the following: any path starting with > / is expanded. This is ambiguous because it could be a valid > path. But then, it is unlikely, and if someone really wants to specify such > a path, it is easy to slap a ./ in front and they're done. I just went back to briefly scan the discussion in late 2018. I think the rough consensus back then was that * It indeed is a problem that there is no syntax for users of "relocatable Git" to use to point at things that come as part of the "relocatable Git" package. * A change to expand_user_path() would be too broad, it makes sense for this feature to be in git_config_pathname(); * We need to get the syntax right. As to the last item, there were a handful of choices raised: - Use "~~"--the downside is that this is not extensible. Use "~runtime-prefix/" would be a better choice (the likelyhood of , $RUNTIME_PREFIX, and any other random choice happens to be used as a valid directory name is just as slim as the likelyhood of "runtime-prefix" used as a valid username). - "$RUNTIME_PREFIX" to make it read like a variable---the downside was that it looked TOO MUCH like a variable and risked user confusion (e.g. it may be upsetting that "$HOME/.gitconfig" is not expanded like "~/.gitconfig" is). - %(RUNTIME-PREFIX) to make it similar to how Git replaces various tokens that are understood only in the context of Git. - ---the downside is that this is an unnecessary new syntax we do not have to introduce. If is unlikely to be used as a valid directory name, %(RUNTIME-PREFIX) is just as unlikely. There might have been other ideas floated back then. I have to say that the one you chose in this round is the least favourite of mine, and if you consulted me privately before redoing this round, I would probably have said %(RUNTIME_PREFIX) would make the most sense among the candidates. Thanks.