Should multiple dependencies pointing to the same git resource but over different schemes in nested dependencies be considered the same dependency?

[devinus]

E.g., this happens now:

* eredis [git: "git@github.com:wooga/eredis.git"]
  locked at "4bcddfd1ae4f48c50c38c96ebace7a49ae2086f3"
  different specs were given for this dependency, choose one in your deps:
$ [ dest: "/Users/devin/Projects/zuul/deps/eredis",
  git: "git@github.com:wooga/eredis.git" ]
$ [ dest: "/Users/devin/Projects/zuul/deps/eredis",
  git: "https://github.com/wooga/eredis.git" ]

[josevalim]

The issue is that any solution in this area is going to be targeted to specific providers, like Github. So if we are going this road, we need to ultimately check Github semantics to see if we can replace git@github.com by https://github.com/ without any meaningful side-effect.

[alexrp]

Well, there are two issues here:

1. I think we should standardize on git://, maybe even warn on any other protocol when pointing to :github deps.
2. Using git@ is a bad idea because it requires authentication (breaks build servers and the like).

[devinus]

@alexrp Did you see: https://github.com/elixir-lang/elixir/commit/aa7400aaadec5495a38185e598a7817cc83381e2 ?

[alexrp]

Nope, but that's good.

Can't we just update the docs to say "use git:// for non-GitHub dependencies that are in Git repositories"?

We could even enforce it, I suppose...

[josevalim]

If they are different sources (i.e. GitHub and non-GitHub), there is nothing we can do. The problem here is when it is the same source (Github in particular) but over different schemas. I am not sure if there is something we can do after all. https is useful for proxies, git should be the default faster one and ssh is required for private repos.

[alindeman]

What about introducing a github-specific syntax like Bundler (in Ruby) has done?

# Gemfile
gem 'rails', github: 'rails/rails'

[devinus]

@alindeman We already have that.

[alindeman]

Oh, nice.

[ericmj]

What is the status of this? Is there anything we can do? If the commit hash we store in mix.lock is the same for both schemes can we assume that they point to the same thing?

If not I think we should leave it as is, if you have a conflict you can override it in your top-level project.

[josevalim]

Yeah, let's just say you need to override it explicitly for now.