linux-kernel - Re: [ANNOUNCE] Git v2.29.0-rc0

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAN0heSrKgNSHKDL07-BWrbF9n6fyWUZVDykdHPCD6CfwgV8QNA@mail.gmail.com>
Date:   Tue, 6 Oct 2020 05:57:02 +0200
From:   Martin Ågren <martin.agren@...il.com>
To:     Junio C Hamano <gitster@...ox.com>
Cc:     Git Mailing List <git@...r.kernel.org>,
        Linux Kernel <linux-kernel@...r.kernel.org>,
        git-packagers@...glegroups.com
Subject: Re: [ANNOUNCE] Git v2.29.0-rc0

Hi Junio,

Thanks for the release candidate!

Minor comments follow.

On Tue, 6 Oct 2020 at 01:00, Junio C Hamano <gitster@...ox.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