Il giorno gio 20 giu 2024 alle ore 00:35 Sam Hartman <hartm...@debian.org> ha scritto: > >>>>> "Salvo" == Salvo Tomaselli <tipos...@tiscali.it> writes: > Salvo> But if by mistake one upstream adds a proprietary file in git > Salvo> and then removes it… we can't distribute the whole .git > Salvo> directory as is. [...] > This same thing can happen with a tar file.
The point here is that history, by its very nature, cannot be "undone". If you ship by mistake a tarball containing a proprietary or otherwise problematic file, you can simply build a new tarball without it. There might be consequences for having distributed the problematic tarball, but the new tarball will be just fine. But if a problematic file slips into your history, and you delete it, that isn't any more the true history. If you are required to release "the complete history", then once anything gets into it, it must stay there forever, otherwise you aren't complying with the requirement. So the problematic file not only taints the current release but EVERY POSSIBLE FUTURE RELEASE. And if you relax the requirement and allow for history to be "edited", where do you draw the line? What is the difference between deleting just one problematic file and deleting everything before an arbitrary point in time? And rebasing a git tree might also be considered "editing history", should that be allowed? Gerardo
