> I just want to push back on the word "regression" here as it is an expected result. Yeah, I wouldn't quite call it a "regression" either; just an inconvenient side effect of a new feature. >> However, it is possible that extra objects are added to the pack-file if the included commits contain certain types of direct renames. > > [1] https://git-scm.com/docs/git-config#Documentation/git-config.txt-packuseSparse > > It is unfortunate that this user hit this problem, but it is easy to work around it I eventually found that note, but not until I figured out that that option was the one causing the trouble. So yes, it is easy to work around this issue when you know about it. Maybe this potential corner case should be given more visibility in the documentation so that it is easier to spot? (Not just on the documentation for the option itself, but maybe in the `git push` one.) > and the benefits of the sparse algorithm should outweigh these kinds of infrequent issues (in my opinion). Well, I don't use git THAT often and still got hit by this issue, so it might not be that uncommon. And when the files are large, the time spent sending them through an internet connection will probably outweigh the processing time saved by skipping some files in the local processing. I wonder if it would make sense to try to make the algorithm smarter to avoid this corner case. For example, ask the server if it already has the objects before sending them, or modify the algorithm to look into trees that have added OR deleted files (to detect that a file has actually been moved, and thus the server must already have it), or simply be extra careful when large files are involved. But I don't know the details of the algorithm so I'm not sure all those suggestions are feasible or even make sense at all.
