The behavior you described seems like what one would generally want to happen.
You wrote: > Though the sha of previous revision is also available in new origin. So, in your scenario, BOTH the origin and the commit history of the Git repo changed. If you don't explicitly specify a ref/branch/tag in the dependency in your `mix.exs` file, then (AFAICT, I couldn't find explicit info in the Mix docs) the default is to use the `HEAD` of the `master` branch. It's not obvious that Mix _will_ update a Git dependency just because the URL changed. That seems like a minor 'cost' regardless – changing repo hosts probably isn't very frequent for almost anyone. If one of your repos is still accessible from GitHub, trying keeping the ref/branch/tag option for the "previous revision" you want to use, but switch the URL back to the GitHub version. Then run `mix deps.get` and that should test the behavior when ONLY the 'origin' (URL) changes. I suspect that Mix will consider the dependency to be up-to-date if the referenced commit is available. On Friday, May 7, 2021 at 10:51:25 PM UTC-4 [email protected] wrote: > Hi there! In the projects I'm working on some dependencies are fetched > directly from private git. First time latest master is fetched and then its > sha is locked in mix.lock. No tags, no branches are used (sure, might be > not the best practice). Lately I was moving "private" libraries from GitHub > to GitLab and updating their sources in mix.exs. So they continue build > in CI as before. However, when I ran *mix deps.get -* lock_status of > private dependencies' evaluates to :*outdated *and deps get updated to > latest master. Though the sha of previous revision is also available in new > origin. > > (Currently I manually reverted parts of mix.lock file to point to the > "previous" revision.) > > Is this a valid use case to not update dependency but only update the uri > of origin in mix.lock file? > > Or maybe introduce new task like mix deps.update_origin <dependency_name>? > -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/3e0a93e0-d2bd-4713-9184-455986a5a69fn%40googlegroups.com.
