B Harder wrote:
Sorry, on mobile and time constrained, but do private branches address this in any way?
I get a lot of mileage out of them, FWIW. When working on the Fossil codebase, I do all my experimental work (which turns out to be most of it...) in private branches. Then when I have something I feel relatively good about, I merge it into a public branch. This way I can fumble around with code I'm unfamiliar with or ideas I'm unsure about without flooding the timeline for everyone else. Richard would probably revoke my commit privileges if I didn't. ;)
For anyone that's interested and doesn't know about/hasn't used private branches, here's a simplified example workflow from when I was working on what eventually became the sbsreloaded branch:
fossil update trunk # Make some changes to diff-related files and start an experimental branch. fossil commit --private --branch diffexp # Make some more changes, committing to this branch as I go along. # ... # Just had an idea for an alternative implementation. # Go back to trunk, make a few changes, and branch again. fossil update trunk fossil commit --private --branch diffexp2 # Make several more commits to this branch before realizing I don't want # to continue down this path. Go back to the original experimental branch. fossil update diffexp # After a bunch of commits, I finally have something I want to share. # Merge it back into trunk and then commit it to a new public branch. fossil update trunk fossil merge diffexp fossil commit --branch sbsreloaded _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
