Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <xmqqa6x070tn.fsf@gitster.c.googlers.com>
In-Reply-To: <xmqqa6x070tn.fsf@gitster.c.googlers.com>
From:   =?UTF-8?Q?Martin_=C3=85gren?= <martin.agren@gmail.com>
Date:   Tue, 6 Oct 2020 05:57:02 +0200
Message-ID: <CAN0heSrKgNSHKDL07-BWrbF9n6fyWUZVDykdHPCD6CfwgV8QNA@mail.gmail.com>
Subject: Re: [ANNOUNCE] Git v2.29.0-rc0
To:     Junio C Hamano <gitster@pobox.com>
Cc:     Git Mailing List <git@vger.kernel.org>,
        Linux Kernel <linux-kernel@vger.kernel.org>,
        git-packagers@googlegroups.com
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Hi Junio,

Thanks for the release candidate!

Minor comments follow.

On Tue, 6 Oct 2020 at 01:00, Junio C Hamano <gitster@pobox.com> wrote:
>  * The final leg of SHA-256 transition plus doc updates.  Note that
>    there is no inter-operability between SHA-1 and SHA-256
>    repositories yet.

I suspect the dash in "inter-operability" should be dropped.

>  * Various callers of run_command API has been modernized.
>    (merge afbdba391e jc/run-command-use-embedded-args later to maint).

s/has/have/

>  * List of options offered and accepted by "git add -i/-p" were
>    inconsistent, which have been corrected.
>    (merge ce910287e7 pw/add-p-allowed-options-fix later to maint).
>
>  * Various callers of run_command API has been modernized.
>    (merge afbdba391e jc/run-command-use-embedded-args later to maint).

Here's that entry again from my previous comment.

>  * "git status" has trouble showing where it came from by interpreting
>    reflog entries that record certain events, e.g. "checkout @{u}", and
>    gives a hard/fatal error.  Even though it inherently is impossible
>    to give a correct answer because the reflog entries lose some
>    information (e.g. "@{u}" does not record what branch the user was
>    on hence which branch 'the upstream' needs to be computed, and even
>    if the record were available, the relationship between branches may
>    have changed), at least hide the error to allow "status" show its
>    output.

s/show/to &/ ?

>  * There is a logic to estimate how many objects are in the
>    repository, which is mean to run once per process invocation, but

s/mean/meant/, I think.

>  * The "unshelve" subcommand of "git p4" used incorrectly used

s/used // (without 'g' flag!)

Martin