From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f47.google.com (mail-ej1-f47.google.com [209.85.218.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7993943E088 for ; Tue, 21 Jul 2026 22:21:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.47 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784672482; cv=none; b=A57OxFbS7HZTZC0jo5GEEY13xbiaorBXsBeuqwCJmr06CvBnG2UeMasIIvWPn2BZHWhFtJFsUwVvMJKn8J9gxEaj3vHZkR+cAkh2ESLKkdhDfe6tBhg9JufKh5irLt1hgfllBxfobXovrpo6/TiIqzu7Hzj2/z7Y0f9dztIO4ZM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784672482; c=relaxed/simple; bh=ZpZ44T0rSR19hOImJZswH81giyKAC8UcNnZhfQcC/ag=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=CqW+eciRdEQ9DYYAW140dnrKQtAtv9/3OTMcg9ZGINZCeEay+NWlmee8NDaOlHAcLqSKaZj7SUXe+csOFs8Ad6Ir3nYBqes+/cg+BC4TF2sCbWm+ShUDnzzcF/Jtk/hv15m0sC2zuXXDxmvk+JROI+PEzLhRCO/6OuigN6hcOLo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=PG7hTzv3; arc=none smtp.client-ip=209.85.218.47 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="PG7hTzv3" Received: by mail-ej1-f47.google.com with SMTP id a640c23a62f3a-c1677c91969so811858966b.1 for ; Tue, 21 Jul 2026 15:21:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1784672479; x=1785277279; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :content-type:mime-version:references:message-id:subject:cc:to:from :date:from:to:cc:subject:date:message-id:reply-to:content-type; bh=qyQeKm+Hbb4jmey+PB9WFih5Y0fv1no1I/iU3jR9Q0Q=; b=PG7hTzv3JE+KyLWhSRlBKuZR9j/2Hawrhegwl/iY8n5mjapS5dnFtAUUut8akp09zA irI+x7GUi2QH99JbrOey8lDQraUoIz/US6Kl9qvFJCUVLKYypwc4aCPOBcCoTklPuCUC jmVAYNu0XK3TikM4B3wuvAjcBB2jiSJq8PPdVm3GTF649BsEjqEPknVmYbLY2QKyM49g LmA+PnXLEP0tlabHCkkC+Xuo0HjIrRdv2JOQ3xkscZacs5m5hubWO9Mozk/EOfCrSecL ASRx2bi3xWxWNhLg/OTCFW7AOHhin2CNue9bRmwEOSM/kQNiqQHDu3X7vUgFSiS8cM/F 1IAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784672479; x=1785277279; h=in-reply-to:content-transfer-encoding:content-disposition :content-type:mime-version:references:message-id:subject:cc:to:from :date:x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to:content-type; bh=qyQeKm+Hbb4jmey+PB9WFih5Y0fv1no1I/iU3jR9Q0Q=; b=WK6XpI5apwNsjTDtnW5aZqj66WsYrBLyFE/zu3HgEI7FuS86qrdsKM7qyTY+3LDrPT 2g0FKy/JWIEiAoJATUJUuLalYEAenbvTrdlhJEBX7HOACSuHbuVbd5ep2OGlGkzXvjG6 zTF81yMCBXPiSu/yUE4xKdr2If/CdK0WLgOFH0ScpA5hckukEjezJUBx4s0qMvZoyJ5B a27VrgJBp4dSbB4V/PWdAawYXE0JbFzgc9Y55nTY7tfkpPU2JqcEKDcxdlzsnJT5F9A4 vRohIxvvY9G71JPyvbSUEV4R4bxC+mmQqCMDWTBBM6SV2dTdi3yVnDm+cB5JDS8xM7El 8JCg== X-Forwarded-Encrypted: i=1; AHgh+RoVmtPhwHd5Bv2lR3aGIi1zelSvkBcidNgfBqvfc3vokwz0wlCWTYY0QbY4cZvoKjhVlVHO2QIMjc4tdGQ=@vger.kernel.org X-Gm-Message-State: AOJu0Yw1pz0BEQ9DACO0tYmkAUxUDKeIabG9iIN1Y1uVsi5xtcIDpMbk NKqRkth73F56RP2yrZSzbFxD0tjj1mKv0qVoYkwrjeO+CiPbQ1eA5D3l X-Gm-Gg: AR+sD13yzhqdx1esPm6+Rg7ZyXkwHzrNE16n1TE/inujQ9wmpbXgN5GLDJnPfTR4UCy ftMKeK9NqR8KBQfFY6oq1ihKCAfYYDzwnFp1Mcx9qPS5pgMeGQEzExADIqAFCSgtPRkrZ87OU4h XIrIyS1CQhdpWIHTllm3yi9DlRVwxkAvKYeY8nQbw/EOnRhrMXqFb1a2ywUmULySxmXXu2W+DPC 2TIsl8C7cPAKnbrjcbcEHa1yz320jW3ogTgsEHrtaNZKjF9vqHIL4JX23k54gqBchLQyR/xPXdI xwTenLXAuUoQ/tYySwvcAsY+PlD61BKKyD/KLMl4rQHa357m/Pyxd9beeOVOXejQrtGlXeFv6jM HayXOT+nP7c46+zyxgUn4MLviB0U1CB685yU6027rTTmbGVRWal2PCPAh1WivF8NRJtfY82+d8x 7/MPrHkZepy4WQBRUwNV6ft6agMvgq X-Received: by 2002:a17:907:9625:b0:c16:101d:7afe with SMTP id a640c23a62f3a-c16b46d34f2mr830437866b.23.1784672478307; Tue, 21 Jul 2026 15:21:18 -0700 (PDT) Received: from localhost (94-21-29-149.pool.digikabel.hu. [94.21.29.149]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c1c32af45ecsm21879266b.28.2026.07.21.15.21.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 21 Jul 2026 15:21:16 -0700 (PDT) Date: Wed, 22 Jul 2026 00:21:14 +0200 From: SZEDER =?utf-8?B?R8OhYm9y?= To: Junio C Hamano Cc: "D. Ben Knoble" , "Yury Norov (NVIDIA)" , git@vger.kernel.org, Thiago Perrotta , Philippe Blain , =?utf-8?B?UnViw6lu?= Justo , Yury Norov , linux-kernel@vger.kernel.org, Codex Subject: Re: [PATCH] completion: complete paths for git send-email Message-ID: References: <20260719134447.381835-1-yury.norov@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Tue, Jul 21, 2026 at 10:09:56AM -0700, Junio C Hamano wrote: > "D. Ben Knoble" writes: > > > On Sun, Jul 19, 2026 at 9:45 AM Yury Norov (NVIDIA) > > wrote: > >> > >> From: Yury Norov > >> > >> git send-email accepts either revisions or paths to patch files, but its > >> Bash completion only offers revisions. This prevents patch files from > >> being completed. It can also make a prefix such as "0" expand to an > >> unrelated hexadecimal ref even when matching 0001-*.patch files exist. > >> > >> In my Linux tree, an attempt to autocomplete the standard-named patch > >> brings a random hashtag: > > > > It is unusual to call this a "hashtag." Perhaps "hash" or "object > > name" (or id) based on the glossary and datamodel docs? > > Very good point, but I am not sure if the author truly meant object > names here. The reproduction test uses a long hexadecimal string, > but that is not an object name; it is an unusual-looking tag name. > It is like naming a topic branch '012345' and complaining that: > > $ git send-email 0 > > completes the input to the branch name while ignoring the > 0001-changes.patch file. > > When you have a branch named '0-tolerance-policy' and: > > $ git send-email 0 > > completes to that branch name, you would not dream of complaining > about the completion. IOW, I think the complaint is somewhat unfair > to begin with. > > Actually, I do not know if the completion script really expands an > abbreviated object name to a full one. I tried: > > $ git rev-parse seen^2 > 179eccf0d01729c19a3238905b951b1880aa4ba1 > $ git checkout master > $ . contrib/completion/git-completion.bash > $ git send-email 17 > > and waited for some time, but it did not complete to anything. We definietely don't do that. I'm not sure what the use-case would be for completing full object names, but considering how many objects a repo might contain, I doubt it can be usable for anything. > In any case, when both a '0001-my-changes.patch' file and a > '0-tolerance-policy' branch exist in your repository and current > working directory, running: > > $ git send-email 0 > > should offer both as candidates, I thihk. Since I only ever pass > filenames to the command, I personally do not think it is a huge > loss if the completion script stops looking at refs and sticks to > filenames only, but others may have a use for that feature. There are a couple of similar Git commands that accept both refs and paths, "diff" and "log" being the obvious examples, and our completion script doesn't list refs and paths for any of them, only refs [1]. I think that's intentional, because: - It's easier to pick the ref you want from a list containing only refs than from a list of refs and paths mixed together, because the list to choose from is shorter, and the unique prefix is likely shorter as well. The same goes for picking the path you want from a list containing only paths. - Even when our completion script only lists refs for a particular command, it's easy to trigger Bash's filename completion via one of the following methods: - git diff ./foo # No ref can start with "./". - git log foo # Bash/readline's keybinding to trigger # filename completion. - git log -- foo # No --options or refs after the # disambiguating doubledash. Although I'm not sure "git send-email" supports the disambiguating doubledash; its completion function surely doesn't. - There is no similarly easy way to trigger refs completion. [1] There are a couple of (sub)commands, like "git worktree add" or "git bungle create", where our completion script lists either paths or refs (but never both) depending on what's already on the command line. But both of these expect a single path followed by a single ref or any revision arguments, so we can unambigously figure out when to list paths and when to list refs. With "diff", "log" and "send-email" this is not possible, because they accept any revision arguments followed by paths.