"Derrick Stolee via GitGitGadget" <gitgitgadget@xxxxxxxxx> 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. > 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.
