Richard Hipp wrote (quoting from several emails): > The problem is that Git now thinks that 9b888fcc is the HEAD of master > and that the true continuation of master (check-in 4f35b3b7 and > beyond) are disconnected check-ins >
Because from the git perspective it _is_ still the HEAD -- there's been no further changes made on top of that commit. The "true" changes are in a separate branch hanging off some historic fork point. I don't understand this part. From the Fossil perspective, moving a > check-in from one branch to another is just adding a new tag to that > check-in. No history is changed. The DAG of check-ins (the block-chain) > is unmodified. Hm. Initially, the commits on the primary branch looked like this: 1. HISTORY - FORK - MISTAKE Then you changed it to this: 2. HISTORY - FORK - FIXED - BEYOND How can you justify the claim that history was unchanged on trunk between time (1) and time (2)? You haven't just added a new check-in to the branch in this situation (which git is more than happy to do via cherry-pick), you've also erased the MISTAKE check-in. What happens to fossil users who updated trunk while MISTAKE was the head? Does the next update somehow pathfind to the new BEYOND head, backtracking via FORK? -Rowan _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
