On Jun 28, 2017, at 5:13 AM, Florian Balmer <florian.bal...@gmail.com> wrote: > > I have a repository with 4 "reparented" check-ins (to skip over > unwanted check-ins)
It appears that you’re trying to treat Fossil like Git. Fossil reparenting is similar to Git rebasing, but it should not be used nearly as frequently. Reparenting is for doing one-time major surgery operations on a Fossil repo, not for everyday use. Better ways to deal with unwanted checkins in Fossil are: 1. Test before checking in. If you don’t have a test suite that can run automatically in a few seconds and catch problems that you can now only see as obviously bad in retrospect, write one. It will pay many other benefits besides catching bogus changes before checkin. 2. Bad checkins at the tip of a branch can be sequestered with “amend --branch” or by editing the checkin in Fossil UI, allowing good development to resume on the “trimmed” tip of that branch. Standard practice is to call that sequestration branch “BROKEN” or similar. 3. If you’re hesitating to do option 2 because some of the children of the bad checkin are good, you can still move the bad checkins to a BROKEN branch, then “fossil merge --cherrypick” to pull individual good checkins back from the BROKEN branch to the repaired working branch. This philosophy preserves the checkin history in proper sequence so that Fossil does not become confused, and it’s no more work than mucking about with reparenting operations. _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
