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.9 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 27CC51F5AF for ; Tue, 30 Mar 2021 17:28:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232416AbhC3R2T (ORCPT ); Tue, 30 Mar 2021 13:28:19 -0400 Received: from pb-smtp21.pobox.com ([173.228.157.53]:59721 "EHLO pb-smtp21.pobox.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232201AbhC3R2Q (ORCPT ); Tue, 30 Mar 2021 13:28:16 -0400 Received: from pb-smtp21.pobox.com (unknown [127.0.0.1]) by pb-smtp21.pobox.com (Postfix) with ESMTP id 4FA6F119192; Tue, 30 Mar 2021 13:28:13 -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=qhE7FU3B4pRtZqBit/nfFHbxtG0=; b=CUTIGP 0cJqFvb8UQPp0U0IyA2VKc6ttTldDwaCdHYLVrLk2z/LC7j4u/Tz9QKZh5jfE6YY ndhqtXDmAyDwvcVriIKgD+TC58TZ1jOwt/O0Xmk8ROfiRFYcA5gYpkqXfiJiHBVd j1jx03AVJLEpjlBtqVRe+4MwTH33z1it8xU9o= 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=x0/9xQSsp2BCSXDcewwgaztWRpQdYmVi nsJFLGB5ZhkofnxvPZNG7y/dXJ88tOOOtcQu1W18LNLBPDDcOZAmSCb4hYUBUKPp p5sCDGHKRjepg0EaIv27wDrTCmIEY4sFjUFOi7mGJ/mB4ycrmByuW171T1NYVWvl bnxB7fFuwxs= Received: from pb-smtp21.sea.icgroup.com (unknown [127.0.0.1]) by pb-smtp21.pobox.com (Postfix) with ESMTP id 47C8E119191; Tue, 30 Mar 2021 13:28:13 -0400 (EDT) (envelope-from junio@pobox.com) Received: from pobox.com (unknown [34.74.119.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pb-smtp21.pobox.com (Postfix) with ESMTPSA id 617AC11918E; Tue, 30 Mar 2021 13:28:09 -0400 (EDT) (envelope-from junio@pobox.com) From: Junio C Hamano To: Chinmoy Chakraborty Cc: git@vger.kernel.org Subject: Re: [PATCH v2] Documentation: updated documentation for git commit --date References: Date: Tue, 30 Mar 2021 10:28:07 -0700 In-Reply-To: (Chinmoy Chakraborty's message of "Tue, 30 Mar 2021 22:08:08 +0530") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1.90 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Pobox-Relay-ID: 4BD547D2-917D-11EB-9AB4-D609E328BF65-77302942!pb-smtp21.pobox.com Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Chinmoy Chakraborty writes: >> [Footnote] >> >> *1* The approxidate is useful when a rough "around that time" >> specification suffices, e.g. "git log --since='last.week'". The >> user is OK to see commits down to roughly a week old, and would >> not be upset if a commit with a timestamp that is 9 days old >> shown. >> >> On the other hand, it would be unusual that somebody cares >> enough to use "git commit --date" but yet it is OK that the time >> recorded is fuzzy. For that reason alone, I am in general >> negative on the direction this patch tries to take us in. > > So according to you, is it a relevant/worthwhile change > > to add in docs? That depends on the "docs". If we do not hint that relative dates are also usable, in addition to the more common date formats like RFC2822 and ISO8601, for "log --since" and other options that are used to specify a boundary for looking up existing things, extending their documentation may be worth doing. Giving 'tea' and other oddities at the top as if they are more important than the formats that is used to give more precise input for options that are used to specify what timestamp is recorded in an object the command is about to create would be a change with negative value. Thanks.