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-Status: No, score=-3.8 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,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 7A0091F66E for ; Tue, 25 Aug 2020 19:40:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726483AbgHYTks (ORCPT ); Tue, 25 Aug 2020 15:40:48 -0400 Received: from pb-smtp2.pobox.com ([64.147.108.71]:63374 "EHLO pb-smtp2.pobox.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726149AbgHYTkq (ORCPT ); Tue, 25 Aug 2020 15:40:46 -0400 Received: from pb-smtp2.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 0792980C31; Tue, 25 Aug 2020 15:40:44 -0400 (EDT) (envelope-from junio@pobox.com) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=sasl; bh=0y3MmtNUMbrvx7T86/6h2ZiRi7A=; b=JZTra1 mzoNfpUY103yPiGMJOsdcDX+1DstVzY1ry4OwS0mVJ+guaUEogmwN74MsKL5oDns 7S4ADNlUC1tF9p3HGoil4VEPHFMVgXsTnhxB4wdPGMrasgc4bWpoSBiVgfA8bo1Q ELfnEYbB8jVP4TLaDUk1uZ3AT3oS8rorIEYlE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; q=dns; s=sasl; b=RfKyKF74Iy/KeT9y//yNH8Kioz3ugSdf o41l2TRfTPjpqt2SOOLJT8o0OBKKT+1+hjBjmMxpjw0bEgLy6ElDJL1gPkPAQisP PZTOT6VXGzlDZzaicF2/nxKDEd//3fN+vAIvbPEAe/zWMV6fDCC/6P/5Fsu7VY/U cuYh8EiGdPI= Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id F240D80C2F; Tue, 25 Aug 2020 15:40:43 -0400 (EDT) (envelope-from junio@pobox.com) Received: from pobox.com (unknown [34.75.7.245]) (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 6FC7080C2D; Tue, 25 Aug 2020 15:40:43 -0400 (EDT) (envelope-from junio@pobox.com) From: Junio C Hamano To: Bryan Turner Cc: Git Users Subject: Re: Mismatched HEAD default behavior from git log References: Date: Tue, 25 Aug 2020 12:40:42 -0700 In-Reply-To: (Bryan Turner's message of "Tue, 25 Aug 2020 12:16:38 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Pobox-Relay-ID: DD2F35A8-E70A-11EA-ACC9-2F5D23BA3BAF-77302942!pb-smtp2.pobox.com Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Bryan Turner writes: > It appears the way --stdin processes input discards nonexistent > commits before the machinery that decides whether you provided any > revs or not runs, and so if every --stdin rev is discarded then you > get the default HEAD. If you provide them via the command line, > though, then it seems like they're discarded later and you don't get a > default. > > I'm not sure whether this is intentional or not (certainly I don't see > it anywhere in the git log documentation for --ignore-missing or > --stdin), but it results in a behavior mismatch that's impossible to > reconcile without requiring extra git processes. I can't always > provide HEAD since, if multiple revs are supplied, if any revs exist > then HEAD would not be included regardless of whether the revs were > supplied via the command line or --stdin. As the intent for adding the "--stdin" option to any subcommand has always been "we may need to feed many many things, that may bust the command line length limit, hence we let you feed these things from the standard input, but otherwise there should be no change in behaviour or semantics", when the behaviour of command line and "--stdin" differ, it is a bug in the latter.