Re: [PATCH 0/8] ahead-behind: new builtin for counting multiple commit ranges

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 6, 2023, 18:26 UTC
Message-ID: <xmqqedq1ag8d.fsf@gitster.g>
In-Reply-To: <pull.1489.git.1678111598.gitgitgadget@gmail.com>

"Derrick Stolee via GitGitGadget" <gitgitgadget@gmail.com> writes:

> These numbers can be computed by 'git rev-list --count B..C' and 'git
> rev-list --count C..B', but there are common needs that benefit from having
> the checks being done in the same process:

This makes readers wonder if "git rev-list --count B...C" should be the end-user facing UI for this new feature, perhaps?

Of course if you are checking how C0, C1, C2,... relate to a single B, the existing rev-list syntax would not work, and makes a totally new subcommand a possibilty.

Show 10 quoted lines

>  2. When a branch is updated, a background job checks if any pull requests
>     that target that branch should be closed because their branches were
>     merged implicitly by that update. These queries can e batched into 'git
>     ahead-behind' calls.
>
> In that second example, we don't need the full ahead/behind counts (although
> it is sufficient to look for branches that are "zero commits ahead", meaning
> they are reachable from the base), so this builtin has an extra '--contains'
> mode that only checks reachability from the base to each of the tips. 'git
> ahead-behind --contains' is sort of the reverse of 'git branch --contains'.

I thought that the reverse of "git branch --contains" was "git branch --merged". "git branch --merged maint ??/\*" is how I cull topic branches that have already served their purpose.

Isn't closing pull requests because they have been already merged the same idea? "git for-each-ref --merged main refs/pull/\*" or something, perhaps?

All of the above are from only reading the cover letter. I'm sure I'll have more thoughts or even change my mind after reading the patches.

Thanks.