Another issue with bundles: "push requests" derived from local private branches.
It may be not only the receiver of a "push request" to decide to import only the final "accumulated patch", without all the detailed "commit-by-commit" history. It may also be the submitter to decide to keep the development history for a "push request" in a local private branch, and only submit the final "accumulated patch", without the full history of all the trials, reverts, and minor coding style and typo fixes. So, the intuitive way for this would be to merge their local private branch into a new branch derived from the same root, and export the new branch to a bundle with the "--standalone" option (the "push request" feature will probably do this, by default). But importing this bundle into the upstream repository, lacking all the knowledge of the local private branch, may have undesired effects. In one of my tests, the /bloblist showed an "unknown" artifact of 0 bytes, with the UUID being one of those listed in the P-card of the imported check-in. Also, not sure if this might lead to problems with future merges, if the parents and merge ancestors referenced by the imported check-in cannot be found in the upstream repository. Bundles are not patches that can be applied freely and flexibly, but tend to rely on the full repository history. --Florian _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
