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.8 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 B81B11F852 for ; Wed, 9 Feb 2022 22:52:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236367AbiBIWsx (ORCPT ); Wed, 9 Feb 2022 17:48:53 -0500 Received: from gmail-smtp-in.l.google.com ([23.128.96.19]:50614 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236322AbiBIWsw (ORCPT ); Wed, 9 Feb 2022 17:48:52 -0500 Received: from pb-smtp2.pobox.com (pb-smtp2.pobox.com [64.147.108.71]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2411FE01976B for ; Wed, 9 Feb 2022 14:48:55 -0800 (PST) Received: from pb-smtp2.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 49D47FF394; Wed, 9 Feb 2022 17:48:54 -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:content-transfer-encoding; s=sasl; bh=OVK9O6x0zYZo +OM8P/7/1MCrpQiyIN9wwJZOds4vqHc=; b=c4DPpLmj5Q9yEEUCgqQaCjdSBEfS VlBw4iBVok8b8TXOdVEfuwrQFdt+zPmGyh6slEBkm+aK85KrCgDvlXCiOTt2gHpS bo/1EUWwJ8GsormRIIRvtz6S+H684MZNtyi/EgEnrFyPRJCHT4vnwg76RojwTuqO /1iREQiY1oSG4II= Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 3C7F8FF392; Wed, 9 Feb 2022 17:48:54 -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 91FC9FF391; Wed, 9 Feb 2022 17:48:53 -0500 (EST) (envelope-from junio@pobox.com) From: Junio C Hamano To: =?utf-8?Q?Ren=C3=A9?= Scharfe Cc: Johannes Schindelin , 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: Wed, 09 Feb 2022 14:48:52 -0800 In-Reply-To: (=?utf-8?Q?=22R?= =?utf-8?Q?en=C3=A9?= Scharfe"'s message of "Tue, 8 Feb 2022 21:58:16 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Pobox-Relay-ID: 74CF1124-89FA-11EC-9D12-CB998F0A682E-77302942!pb-smtp2.pobox.com Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Ren=C3=A9 Scharfe writes: >>> 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? > > Kind of. Command line arguments are built and handed to write_archive(= ) > in-process. It's done by patch 3 and extended by 5 and 6. I meant to ask if this is doing git archive --store-contents-at-path=3D"report.zip:$(cat diag.zip)" as I misunderstood what 'the diagnostic .zip file' referred to. That was a reference to the output of the "git archive" command. > The number of files is relatively low and they aren't huge, right? As long as it is expected to fit on the command line, that's fine. But if the question is "it is OK to add a new option with known limitation", then it should be stated a bit differently. "We add this option for use cases where we handle only small number of one-liner files", and it is OK. We may however want to do something imilar to what we do to the "-m ''" option used by "git commit" and "git merge", i.e. add the final LF when it is missing to make it a complete line, to hint the fact that this is meant to add a small number of single liner files. >> Another worry was that when can have >> arbitrary bytes, with --opt=3D: syntax, the input >> becomes ambiguous (i.e. "which colon is the separator?"), >> without some way to escape a colon in the payload. > > The first colon is the separator here. Meaning you cannot have a colon in the path, which is not exactly pleasing limitation. I know you may not be able to do so on Windows or CIFS mounted on non-Windows, but we do not limit ourselves to portable filename character set (POSIX.1 3.282), either. >> 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/ > > I don't see the conflict: If an untracked file is added to an archive > using --add-file, --add-file-with-content, or ZIP or tar then we'd > *want* the verification against a signed commit or tag to fail, no? A > different signature would be required for the non-tracked parts. Yes, which is exactly how this (and existing --add-file) makes Konstantin's plan much less useful. Thanks.