Skip to content

Conversation

@Leonidas-from-XIV
Copy link
Collaborator

This PR applies #13176 and adds the remaining code to implement the behavior discussed in #13110. The tests change accordingly with the changed semantics of git URLs.

Closes #13110

@Leonidas-from-XIV Leonidas-from-XIV force-pushed the lock-git-revision-take-2 branch 2 times, most recently from d669f81 to 64a79d3 Compare January 12, 2026 22:01
Copy link
Collaborator

@Alizter Alizter left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you add test cases for branches and tags?

@Leonidas-from-XIV Leonidas-from-XIV marked this pull request as draft January 14, 2026 15:24
@Leonidas-from-XIV Leonidas-from-XIV force-pushed the lock-git-revision-take-2 branch 4 times, most recently from b0992b8 to b8da39b Compare January 16, 2026 09:29
@Leonidas-from-XIV
Copy link
Collaborator Author

Currently blocked by #13333 to figure out what to do with the failing tests.

@Leonidas-from-XIV
Copy link
Collaborator Author

I've added tests for tags & branches and a solution for the issue that's described in #13333. This should solve the problem with failing tests.

Leonidas-from-XIV added a commit that referenced this pull request Jan 20, 2026
…13396)

In `rev_store.ml` we currently try to create the rev-store folder and if
it exists then we assume that it is a bare repo. This is not necessarily
the case and if the folder is e.g. empty (because a previous `init
--bare` failed) the rev-store is permanently bricked with no way to
recover (bar the user removing it but it is unclear from the error what
the user can do, as `git` points at somewhere else).

Noticed this behavior when pairing on a strange test failure on #13297
with @Alizter and paired with @Sudha247 to create a repro case.

This PR is a variant of #13392 which reproduces the same behavior using
a different approach which does not require the changes from #13297.

Signed-off-by: Marek Kubica <marek@tarides.com>
@Leonidas-from-XIV Leonidas-from-XIV dismissed Alizter’s stale review January 21, 2026 10:59

Change request adressed

Signed-off-by: Marek Kubica <marek@tarides.com>
Signed-off-by: Marek Kubica <marek@tarides.com>
Signed-off-by: Marek Kubica <marek@tarides.com>
Signed-off-by: Marek Kubica <marek@tarides.com>
Signed-off-by: Marek Kubica <marek@tarides.com>
Signed-off-by: Marek Kubica <marek@tarides.com>
@@ -0,0 +1,55 @@
#!/bin/bash

# dummy implementation of just enough git to be able to create a lock file
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A bit surprised that you need this. Isn't it possible to use a remote that is on the local file system? Or does that not test everything?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The opam-source-conversions.t test tries multiple types of remotes:

  • git+file which can be tested by redirecting it to an existing local repo (see the second commit in this PR)
  • git+http which would need to be redirected to a local HTTP server. Possible but given how many issues the one-shot HTTP server had, I'd rather not launch and interact with an HTTP server in Cram tests.
  • git+foobar can't really be tested locally.

I've created #13333 to discuss this issue and it seemed to me that fitting in a fake git in the git+http and git+foobar cases would be the best course of action.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, so the tests are using the real git binary for git+file then?

Copy link
Collaborator Author

@Leonidas-from-XIV Leonidas-from-XIV Jan 23, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it is only used in the git+http and git+foobar cases where our fake git binary in _bin/git is injected via

  $ PATH=_bin:$PATH solve testpkg

The git+file case uses the real git binary provided by the system. I've specifically tested that it resolves correctly because I remember that there is some weirdness when setting environment variables in front of function calls on sh. But given we run with bash this issue is not happening.

Signed-off-by: Marek Kubica <marek@tarides.com>
resolve_package name (OpamPackage.version opam_package)
in
let+ resolved_pkgs =
resolve_opam_packages opam_packages_to_lock ~resolve_package
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about passing the table instead of the function? I prefer first order code when possible.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree, however the resolve_package function is used further down, where in computes ocaml, so I can't completely eliminate it without major rewriting.

Signed-off-by: Marek Kubica <marek@tarides.com>
@Leonidas-from-XIV Leonidas-from-XIV merged commit 265ecbf into ocaml:main Jan 23, 2026
28 checks passed
@Leonidas-from-XIV Leonidas-from-XIV deleted the lock-git-revision-take-2 branch January 23, 2026 17:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Pinning a git repo should record the hash of the repository in the lock

3 participants