> So, in your scenario, BOTH the origin and the commit history of the Git repo changed.
I might not describe it clearly enough.. But commit history is the same. Only origin has changed. > 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. That was my expectation as well.. but it doesn't work like that. It updates to the latest rev.. I did that with multiple repos with elixir 1.8.2 and elixir 1.11.4 I tracked it down to this part of Mix.SCM.Git.lock_status/1 <https://github.com/elixir-lang/elixir/blob/master/lib/mix/lib/mix/scm/git.ex#L67> where get_lock_rev/2 <https://github.com/elixir-lang/elixir/blob/master/lib/mix/lib/mix/scm/git.ex#L209-L213> returns nil because first condition in if-expression *(repo == opts[:git])* is not satisfied because *repo* here is new origin and *opts[:git]* is old origin. And as a result it always fails into the final condition `true -> :outadated` I see in docs for Mix.SCM.lock_status/1callback <https://github.com/elixir-lang/elixir/blob/master/lib/mix/lib/mix/scm.ex#L106-L108> it says: > Note the lock may also belong to another SCM and as such, an > structural check is required. A structural mismatch should always > return `:outdated`. But I don't think that's the case. On Sunday, May 9, 2021 at 10:37:38 AM UTC-7 [email protected] wrote: > 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/be96f2b5-55bc-4a10-8b61-93e3f1c9bbbfn%40googlegroups.com.
