Hmm – I'm definitely confused because you mentioned "the sha of previous revision is also available in new origin" in your first message.
And then you mentioned "It updates to the latest rev." in your last message. Can you share the portion of the `deps/0` function for this dependency from your `mix.exs` file? (You can and should redact the URL and change the name if either is sensitive.) Assuming there's no difference in the commit history between the two remote repos, it's a good question whether changing the remote repo URL is a "structural mismatch". I can sympathize with the possible decision by the Mix folk to just re-fetch the dep in this case tho. And, worst case, it still seems like this would just be a one time 'cost', i.e. the dependency will be re-downloaded after changing the repo URL, but just once (until the repo itself, or the portion referenced in the dependency info, is updated). On Sunday, May 9, 2021 at 5:41:35 PM UTC-4 [email protected] wrote: > > > 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/5172d1a7-3871-481e-be12-b31f2d7bc5ddn%40googlegroups.com.
