Patrick Steinhardt <ps@xxxxxx> writes: >> And if my suspicion is correct, all this change does to the plain >> vanilla user of "git rerere gc" is to have them pay the extra cost >> of allocating and deallocating the list of names of paths in string >> lists. > > Yeah, I think this concern makes sense indeed. I was a bit sceptical > myself whether this is going too far. Maybe a simpler solution would be > to just count the number of directories in ".git/rr-cache", without > checking whether those actually are prunable? I dunno. It is not like you are guestimating files under .git/objects/??/ without couting all of them, just to see if you have too many of them and reduce them by repacking and/or pruning. Having too many existing rerere entries does not correleate you would have many prunable ones. If your development is nearly linear and you do not rebuild the same merges over and over every day, majority of rerere entries may be created and recorded without ever getting used even once. On the other hand, in my tree, where the same merges along master..jch first-parent history are recreated multiple times every day, the picture would be different. > We could also adapt this to be closer to the original version, where we > only verified that ".git/rr-cache" exists and contains at least one > subdirectory. This can even be combined with the above approach if we > set "maintenance.rerere-gc.auto=1" by default. But wouldn't that be like always running "rerere gc"? What would you save by checking the existence of at least one rerere entry? Cost to spawn "rerere gc" as a subprocess? Wouldn't it be a better use of the engineering effort to libify the logic of that process and make it internally callable in the longer term (or are you already doing that in this series)? >> We need to see some performance measurement to show that the we pay >> for collection and counting is a lot smaller compared to the whole >> pruning operation to justify the "auto" thing. > > Hm. I guess ultimately the answer is going to be "it depends". The > performance implication on Windows is going to be quite different > compared to the performance on Linux/macOS. Yes, but we need to start somewhere ;-)
