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

Reply via email to