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=0.3 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,T_SCC_BODY_TEXT_LINE 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 EF3781F852 for ; Tue, 8 Feb 2022 17:44:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348380AbiBHRoh (ORCPT ); Tue, 8 Feb 2022 12:44:37 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35990 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229496AbiBHRoe (ORCPT ); Tue, 8 Feb 2022 12:44:34 -0500 Received: from pb-smtp2.pobox.com (pb-smtp2.pobox.com [64.147.108.71]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 773A4C061578 for ; Tue, 8 Feb 2022 09:44:33 -0800 (PST) Received: from pb-smtp2.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id F100E119FFB; Tue, 8 Feb 2022 12:44:30 -0500 (EST) (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=itXVXQpsI1qIpy4w3fNDflagNEnEf5Rd16eAeE 72MGg=; b=nvw2U6OHmTCmtd3+ogV80PgzzYRQGteEF97G1S2y20f9oDUDKTqlCf iTiP6pVcRi9DQcWxMOiVYA/2oYt131J+14jT9w5PuQkayEU8JyCQ+yHgXPgHD7Ij 5kvQCrey5ufHG7BCvA1j7CffmcxRaH6HPiy+KEqQkJd3cLhaj3A0k= Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id E679B119FFA; Tue, 8 Feb 2022 12:44:30 -0500 (EST) (envelope-from junio@pobox.com) Received: from pobox.com (unknown [35.185.212.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id 4CDB7119FF9; Tue, 8 Feb 2022 12:44:30 -0500 (EST) (envelope-from junio@pobox.com) From: Junio C Hamano To: Johannes Schindelin Cc: =?utf-8?Q?Ren=C3=A9?= Scharfe , Johannes Schindelin via GitGitGadget , git@vger.kernel.org, Taylor Blau , Derrick Stolee , Elijah Newren Subject: Re: [PATCH v2 1/6] archive: optionally add "virtual" files References: <49ff3c1f2b32b16df2b4216aa016d715b6de46bc.1644187146.git.gitgitgadget@gmail.com> Date: Tue, 08 Feb 2022 09:44:28 -0800 In-Reply-To: (Johannes Schindelin's message of "Tue, 8 Feb 2022 14:12:21 +0100 (CET)") 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: C4A1B5B6-8906-11EC-BDFC-CB998F0A682E-77302942!pb-smtp2.pobox.com Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Johannes Schindelin writes: >> > We could use that option in Git's own Makefile to add the file named >> > "version", which contains $GIT_VERSION. Hmm, but it also contains a >> > terminating newline, which would be a bit tricky (but not impossible) to >> > add. Would it make sense to add one automatically if it's missing (e.g. >> > with strbuf_complete_line)? Not sure. >> >> I do not think it is a good UI to give raw file content from the >> command line, which will be usable only for trivial, even single >> liner files, and forces people to learn two parallel option, one >> for trivial ones and the other for contents with meaningful size. > > Nevertheless, it is still the most elegant way that I can think of to > generate a diagnostic `.zip` file without messing up the very things that > are to be diagnosed: the repository and the worktree. Puzzled. Are you feeding contents of a .zip file from the command line? I was mostly worried about busting command line argument limit by trying to feed too many bytes, as the ceiling is fairly low on some platforms. Another worry was that when can have arbitrary bytes, with --opt=: syntax, the input becomes ambiguous (i.e. "which colon is the separator?"), without some way to escape a colon in the payload. For a single-liner, --add-file-with-contents=: would be an OK way, and my comment was not a strong objection against this new option existing. It was primarily an objection against changing the way to add the 'version' file in our "make dist" procedure to use it anyway. But now I think about it more, I am becoming less happy about it existing in the first place. This will throw another monkey wrench to Konstantin's plan [*] to make "git archive" output verifiable with the signature on original Git objects, but it is not a new problem ;-) [Reference] * https://lore.kernel.org/git/20220207213449.ljqjhdx4f45a3lx5@meerkat.local/