Updating clone of sqlite repository stuck in 493a2594
Hello Richard ! I'm following sqlite development daily for years and before there was occasional problems when you let's call it "rebased" the trunk and I was left stuck with a dead branch, but now looking at the timeline it doesn't seem that I'm in a dead branch but somehow every time I do "fossil update" I'm stuck on this checkout 493a2594 . How to fix this ? There is a way for fossil to recognize situations like the described above and issue a warning/recommendation to fix it ? ==== fossil update Autosync: https://www3.sqlite.org/cgi/src Round-trips: 1 Artifacts sent: 0 received: 0 Pull done, sent: 1308 received: 991 ip: 184.108.40.206 ------------------------------------------------------------------------------- checkout: 493a25949b9a6d0be82169b597133e491d8be4f4 2020-08-24 10:52:52 UTC tags: trunk comment: Correctly handle expressions like "x IS (not) true/false" within the rhs of IN() expressions. Fix for [f3ff1472]. (user: dan) changes: None. Already up-to-date mingo@mingo-X550VX:~/dev/dadbiz++/third-party/dad/sqlite3$ fossil status repository: /home/mingo/dev/dadbiz++/third-party/dad/sqlite.fossil local-root: /home/mingo/dev/dadbiz++/third-party/dad/sqlite3/ config-db: /home/mingo/.fossil checkout: 493a25949b9a6d0be82169b597133e491d8be4f4 2020-08-24 10:52:52 UTC parent: 5f58dd3a19605b6f49b4364fa29892502eff35f1 2020-08-20 16:25:26 UTC tags: trunk comment: Correctly handle expressions like "x IS (not) true/false" within the rhs of IN() expressions. Fix for [f3ff1472]. (user: dan) ==== Cheers !
The problem isn’t due to “rebasing,” which you can’t do in Fossil anyway. (On purpose.)
The fix is to switch the clone URL:
$ fossil remote https://sqlite.org/src/
I suspect your past problems were due to post-facto branch retagging, which may look superficially like rebasing, but isn’t. It’s rare enough that I wouldn’t change a manual workflow, since it’s easy to cope. Say:
$ fossil up trunk
If you have an automated update mechanism, just use that command instead of making the branch implicit.
Briefly, the problem is that Fossil doesn’t remember the current branch name, it remembers the current commit ID. When that commit gets relabeled, it stays on that newly named branch, rather than send you off to what it perceives to be a different branch.
Further discussion on this topic is better taken up on the Fossil forum, where we did in fact cover it recently, though I’m having trouble finding the thread at the moment. (The relevant keywords are too common, so they pull up tons of irrelevant threads.)