Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: > I think the "git fetch --dry-run" command behaves like this too, > i.e. doesn't update refs, but fetches and writes objects. > > For the patch I hacked up I think it's easy to argue that it shouldn't > do compression etc. > > For this sort of thing and "fetch" I'm not so sure. Do we really know > that there aren't people who rely on this for say the performance of > seeing what an operation would do, and then not pay as much for the > "real one" that updates the index/refs/etc. later? Is that subsequent > "fetch" cheaper because of the --dry-run? The answer to the last one is an easy "yes". Trying to gauge the time it would take for a real fetch with "--dry-run" is a losing battle, I would think, as the pre-fetching would make the "real" one cheaper, so from that point of view, I think we can ignore those who time "--dry-run" and try to figure out anything meaningful. This in any case is an interesting area, as the definition of correctness of what "dry-run" does can be quite fuzzy. As long as it does not change the index, "git add --dry-run", even if it writes objects or detects filesystem corruption by noticing I/O error while compressing the data taken from the working tree files, is still correct and the patch in question is not technically a bugfix (it is a performance thing). "git fetch --dry-run" would fall into the same category, so would "git hash-object" without "-w". All can use performance enhancement without breaking existing users, I would think. Thanks.
