Provide a way to list orphaned commits

[clime]

I generated a static delta in one repo and then applied it (ostree static-deta apply-offline) to another previously empty repo. Afterwards, i had a hard time to find the new commit that was created by appling that delta. Is there a way to browse all the commits that are present in the repository, not only those that are assigned to a certain branch?

[clime]

This is a problem also if I pull a commit into existing branch that is not a child of the already existing commit in the branch. The old commit is still somewhere there because i can see fsck checks two commits for consistency (not just one), but only the new commit is displayed when i invoke ostree log <branchname>.

[jlebon]

Is there a way to browse all the commits that are present in the repository, not only those that are assigned to a certain branch?

Yeah, we should make that easier. I've used find objects/ -name '*.commit' in the past.

This is a problem also if I pull a commit into existing branch that is not a child of the already existing commit in the branch.

If the new commit isn't a child of the parent, then the parent becomes an orphan. Like git, orphan objects can accumulate over time. You can use ostree prune to delete those (like git). In sysroot contexts, this GC type stuff is automatically done when e.g. a new deployment is made.

[clime]

Is there a way to browse all the commits that are present in the repository, not only those that are assigned to a certain branch?

Yeah, we should make that easier. I've used find objects/ -name '*.commit' in the past.

How do you get to the actual hashes of the commits found like that so that you can e.g. delete them?

[jlebon]

How do you get to the actual hashes of the commits found like that so that you can e.g. delete them?

Have you tried ostree prune? It should delete them for you. The checksum itself is encoded in the name of the commit object, with the first two hex characters used as the directory.

[clime]

Hello, well i wanted to delete them by ostree prune --delete-commit <commit-hash>. Just ostree prune doesn't delete orphaned commits according to my attempts.

Do you happen to know encoding of the checksum?

Anyway, I just wanted to say i find it really frustrating that i know there is something there that i cannot list or get a handle of. In the end, i had wrote a custom script that lists the commit ids based on the first two characters of the checksum that i can find out with the find command you gave me but i think it would be good to have this feature included in the ostree interface somehow.

[jlebon]

Hello, well i wanted to delete them by ostree prune --delete-commit . Just ostree prune doesn't delete orphaned commits according to my attempts.

Right yeah, you need ostree prune --refs-only. ostree prune on its own will not delete orphaned commits, just orphaned objects which don't belong to any commit (orphaned or not).

Anyway, I just wanted to say i find it really frustrating that i know there is something there that i cannot list or get a handle of

Yeah, I don't disagree. :) Probably the closest thing is ostree prune --refs-only --no-prune -v. Hmm, kinda awkward though maybe we want like ostree refs --show-orphan-commits?

[clime]

Hello, well i wanted to delete them by ostree prune --delete-commit . Just ostree prune doesn't delete orphaned commits according to my attempts.

Right yeah, you need ostree prune --refs-only. ostree prune on its own will not delete orphaned commits, just orphaned objects which don't belong to any commit (orphaned or not).

Anyway, I just wanted to say i find it really frustrating that i know there is something there that i cannot list or get a handle of

Yeah, I don't disagree. :) Probably the closest thing is ostree prune --refs-only --no-prune -v. Hmm, kinda awkward though maybe we want like ostree refs --show-orphan-commits?

Sounds good to me. I was thinking about adding that param to log subcommand although disadvantage would be that the output would look like all the commits are in parent-child relationships when that wouldn't necessarily be the case. But I think it could be just described in the man page.

[clime]

Anyway, both options are good, I would be happy for any of them.