Fossil Forum

Just a quick idea away from PC and docs and such: try fossil rebuild.

Doesn't make a difference. I've wondered about closing the pre-merge commit but I'm sort of afraid to mess things up (but I suppose I can just copy and fossil remote off to experiment, heh).

So you're saying that Fossil does not identify C7 as a leaf node but it instead thinks that C5 is the leaf? What does Fossil think C7 is?

Does it show up in the output of "fossil leaves" or "fossil leaves -c"? If you clone it does it happen on the clone as well?

What about "fossil info trunk"? Or "fossil info C5" and "fossil info C7" where C5 and C7 are their hashes respectively?

Also, maybe "fossil whatis C5" and "fossil whatis C7"?

One thing to try after investigation is "fossil leaves --recompute" to see if that changes it.

I could provide access to the repository to one of the Fossil developers, temporarily, to see what you can find.

i'd be happy to take a look at this (email is here), with solemn vows to (A) not distribute it further and (B) delete all traces of it upon completion. After making a copy, run "fossil scrub --verily" on that copy to delete any potentially-sensitive info from it.

Since you recently posted a patch to libfossil, a specific question: did you use any of libfossil's tools on that repo? Some 5+ years ago it had a bug where it would not update the "leaf" entries properly, causing what looked like what you are seeing (with or without the merge). That was fixed a ages ago, but its similarity to your problem causes a bit of a traumatic flashback for me.

As Florian suggested, i'd fully expect a rebuild to resolve that, as the leaves are nuked and recalculated there. That that is not resolving it points to a larger mystery.

TIL (from Andy B.):

One thing to try after investigation is "fossil leaves --recompute" to see if that changes it.

18 years in and fossil still has features i didn't know about.

Edit:

I've wondered about closing the pre-merge commit but I'm sort of afraid to mess things up

It's actually very difficult, barring (A) the shun command or (B) direct SQL manipulation (which is largely futile), to get a fossil repo completely hosed.

Since you recently posted a patch to libfossil, a specific question: did you use any of libfossil's tools on that repo?

I did not, that was related to a difference repository, and to be honest, I ended up not using libfossil at all. :)

The problem repository in this thread has only ever been used by the official Fossil binary. No libfossil, no sqlite3 shenanigans, etc.

One thing to try after investigation is "fossil leaves --recompute" to see if that changes it.

18 years in and fossil still has features i didn't know about.

Same here. It appears to have resolved my problem, and I assume that means there wasn't anything particularly funky about the manifests. Might be why I have been unable to create a test-case repository that exhibits the same problem.

I could still send the repository in the funky state, but perhaps it's not necessary anymore. I trust you, but it might be more trouble than it's worth.

I've wondered about closing the pre-merge commit but I'm sort of afraid to mess things up

It's actually very difficult, barring (A) the shun command or (B) direct SQL manipulation (which is largely futile), to get a fossil repo completely hosed.

That's all true. I did do some experiments by just copying the repository and setting fossil remote off on the copy. I'm happier I don't need to futz around with creating new manifests though.

Mind that this core issue is apparently resolved with your suggestion of fossil leaves --recomputer. Thanks for that.

Working from the "funky" state:

So you're saying that Fossil does not identify C7 as a leaf node but it instead thinks that C5 is the leaf? What does Fossil think C7 is?

That's correct. It simply shows C7 as a check-in with tag: trunk. The timeline shows C5 as the leaf.

Does it show up in the output of "fossil leaves" or "fossil leaves -c"? If you clone it does it happen on the clone as well?

Only C6 and C5 show in the output of fossil leaves. That stays preserved on a clone.

What about "fossil info trunk"? Or "fossil info C5" and "fossil info C7" where C5 and C7 are their hashes respectively?

fossil info trunk shows C7, presumably because it is the most recent check-in on trunk. fossil info C5 displays two children and a merged-into hash(^ It's probably actually one child in the sterilized example I contrived, I have yet another branch in my real repo that came from C5, though the problem manifested (no pun intended) prior to the creation of that secondary branch.)

Also, maybe "fossil whatis C5" and "fossil whatis C7"?

All looking normal to me.

Hmm, and I just noticed that /brlist doesn't show trunk anymore, nor does fossil branch list. How odd.

Edit: seems that if I edit the initial check-in and "move to branch trunk" (despite that it's already there), it resolves this issue too. This is leaving me confused.

Edit: seems that if I edit the initial check-in and "move to branch trunk" (despite that it's already there), it resolves this issue too. This is leaving me confused.

Just spitballing, but a question to those who have experience with "fossil import": if the repo in question were (hypothetically) imported from git, could that in itself account for symptoms like what Mike is reporting? e.g. a cross-wiring of the main branch name or some such? (i've no clue - never once imported from git, and am just grasping at straws here.)

It's not particularly sensitive information to reveal it was converted from Git. :-)

Even still, attempting to create a trivial repository in Git, importing it, and continuing work in Fossil, I have been unable to reproduce the problem I've encountered in the opening post.

I could provide access to the repository to one of the Fossil developers, temporarily, to see what you can find.

(After having poked around it...)

i'm at a loss to explain what you're seeing, but there is another related curiosity:

fossil branch ls

is empty, whereas:

fossil branch ls -all (or -closed)

shows two branches, neither of them named "trunk" or "main" (from git).

That probably explains why "rebuild" does not recompute the leaves properly, but it doesn't readily explain to me why "leaves --recompute" can cope with that (which may indicate a bug in rebuild, as it's clearly calculating the leaves differently). A rebuild is leaving (haha!) me with no leaves (down from the initial incorrect one).

Even after 'leaves --recompute', it's still showing me no opened branches and only the same two closed ones, which is certain to cause downstream issues. Moving the checkin to trunk was the right thing to do, but i'll recommend that you go back and do the same to the very first checkin so that the history leading up to that point gets (hopefully) straightened out.

i think the reason you're seeing things as on the trunk, despite them not really being there, is that fossil generally assumes that all checkins are in some branch or other and, as a fallback, will assume trunk.

This is almost certainly a side-effect of having imported the repo, but my git-foo is as close to zero as it gets, so where this might be going wrong is a complete mystery to me.

Edit:

The initial checkin does get assigned to trunk but it's missing half of the tag. Looking at the initial checkin of some arbitrary repos we'll see:

T *branch * trunk
T *sym-trunk *

Whereas the broken repo is missing that first line, which means that it's not been assigned to a branch. That sounds like an import bug. Using "amend" or the UI to "move" the initial checkin to "trunk" should resolve the whole thing.

The initial checkin does get assigned to trunk but it's missing half of the tag. Looking at the initial checkin of some arbitrary repos we'll see:

T *branch * trunk
T *sym-trunk *

Whereas the broken repo is missing that first line, which means that it's not been assigned to a branch. That sounds like an import bug. Using "amend" or the UI to "move" the initial checkin to "trunk" should resolve the whole thing.

That at least explains why my workaround I discovered in post 8.1 works, and will make me more comfortable applying it to the real repository (I had only played with it on copies/tests).

Thanks for your help, much appreciated. :-)

neither of them named "trunk" or "main" (from git).

To be honest, it never would have been called main. I purposefully force Git to always use master:

.gitconfig: [init] defaultBranch = master

Plus the repository dates from way before anyone was attempting to change that.

With a clue in Stephan's response to the issue, I've started to be able to reproduce problem repositories where T *branch * trunk is missing from the original repository, though I am not satisfied that it replicates the issue from the original repository the thread had. It requires that branch names are preserved in a Git fast-export.(^ This is not the norm for Git, nor was it the case in the original repository. Git branch names must be unique, and it is therefore standard practice to delete branch references after you are done with them. When importing a typical Git repository, old branches instead show up as forks on master.)

The fast-import stream is compressed and turned to base64 here to make sure nothing goes wrong copy-pasting to and from the forum, but it's trivially decoded to the original text if you want to examine it too.

$ base64 -d <<EOF | zstd -dc | fossil import --git --rename-master trunk test.fossil KLUv/WTQAf0EADIIGheAbQOItPTAACLoSJJAAzCMld0EsbCZ9plOWLbCd4TsS2g3357NteaWCUuo S89ke68lO3KVIy8d13oLULZrcMO+x9Ro6PFCIwlGXCXa0IPoS06cOBmh0LM/7pKSjQrgwu0EkOnX 2LA/GCBglUQdmUAHEge7YXI3uOWSIvdmdlOQ58OrM3jY4UnmKEadbJ49zBCmk7/gYawLQ0SPAcGj RtE= EOF $ fossil ui test.fossil

If you browse then to /artifact/9776674f3fc4b7db, the manifest starts out with T *branch * v2. It doesn't quite exhibit the leaves problem nor the brlist problem, but it's still an oddity that would have to be corrected with fossil amend 9776674f3f --branch trunk.

Perhaps that's the real lesson, that repositories imported from Git almost always need some "clean up" with amendment artifacts.