On Thu, Mar 26, 2020 at 08:32:38PM +0000, Daniel Shahaf wrote: > What I'm worried about is that we'll apply the "backwards compatibility > until 2.0" promise to something we shouldn't. As I said, issues of > this nature can't generally be found by tests; they can only be found > by code review.
I'm not worried about that. After reading through the patch I don't see any reason why we would not want to commit to supporting this feature. Do you have concrete concerns? I can't see any downsides. So far, I believe this new subcommand will be very useful. The only existing alternative is a full dump/load which is expensive to perform on large repositories. I've seen several cases in recent years were servers were upgraded but admins decided against doing a full dump/load cycle of repositories sized in the GB/TB range because the perceived benefits didn't justify the extra effort. I know of at least two cases where rep-sharing was temporarily or perhaps even permanently disabled after SHA1 collisions were committed (one case is webkit, I learned about another case via elego's SVN support). These repositories are now growing faster than they would if rep-caching could be re-enabled easily.
