On 3/10/2023 2:16 PM, Junio C Hamano wrote: > "Derrick Stolee via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes: >> However, '%(ahead-behind:)' computations are likely to be slow no matter >> what without a commit-graph, so assuming an existing commit-graph file is >> reasonable. If we find sufficient desire to have an implementation that does >> not have this requirement, we could create a second implementation and >> toggle to it when generation_numbers_enabled() returns false. > > At that point, it might make sense to find a way to make the work > ensure_generations_valid() had to spend cycles on not to go to > waste. Something like "ah, you do not have commit-graph at all, so > let's try to create one if you can write into the repository" at the > beginning of the function, or something? Just thinking aloud. This is a reasonable idea for helping users get out of a slow situation. Let's see how often this is a problem to see if it is worth doing that extra work in another series. > Having read all the patches, I am very impressed and pleased, but > are we losing anything by having the feature inside for-each-ref > compared to a new command ahead-behind? As far as I can tell, the > new "for-each-ref --stdin" would still want to match refs and work > only on refs, but there shouldn't be any reason for ahead-behind > computation to limit to tips that are at the tip of a ref, so that > may be one downside in this updated design. For the intended use > case of "let's find which branches are stale", that downside does > not matter in practice, but for other use cases people will think > of in the future, the limitation might matter (at which time we can > easily resurrect the other subcommand, using the internal machinery > we have here, so it is not a huge deal, I presume). I think the for-each-ref implementation solves the use case we had in mind, I think. I'll double-check to see if we ever use exact commit IDs instead of reference names, but I think these callers are rarely interested in an exact commit ID but instead want the latest version of refs. The idea of using committish tips definitely changes the functionality boundary. You are right that we can introduce a new builtin easily if that is necessary. Even without the ahead-behind builtin, we are succeeding in reducing the diff between our fork and the core project. Thanks, -Stolee
