As far as I can tell, what’s being said here is that commit A is available on GitHub. They moved to Gitlab and have done further development, and the current HEAD is commit B. The process of moving from GitHub to Gitlab did not cause commit A to fall off.
When the repo URL is changed from github.com to gitlab.com, Mix detects this and refetches the current HEAD for the target branch, getting commit B. But commit A is still available on gitlab, so it feels like this update shouldn’t be necessary. I suspect that there’s no good fix for this other than tagging commit A and specifying that tag as part of the dependency. -a On Mon, May 10, 2021 at 11:07 AM Kenny Evitt <[email protected]> wrote: > > 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 where >> get_lock_rev/2 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 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. -- Austin Ziegler • [email protected] • [email protected] http://www.halostatue.ca/ • http://twitter.com/halostatue -- 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/CAJ4ekQuEyT-CO2Zg-8JaGEHuJZYL6up42woFf6oZq%2BVumKDMdg%40mail.gmail.com.
