GitoxideLabs / gitoxide

An idiomatic, lean, fast & safe pure Rust implementation of Git
Apache License 2.0
8.99k stars 310 forks source link

`gix tool organize` does not support aliased URLs #84

Open K900 opened 3 years ago

K900 commented 3 years ago

There's a somewhat lesser known feature in git where you can use aliases for your remote URLs by putting something like

[url "ssh://git@github.com/"]
    insteadOf = "gh:"

And then use git clone gh:Byron/gitoxide instead of typing out the entire URL.

As of 0.9, gitoxide fails to parse those remotes:

~/scratch
❯ git clone gh:Byron/gitoxide
Cloning into 'gitoxide'...
remote: Enumerating objects: 24757, done.
remote: Counting objects: 100% (5485/5485), done.
remote: Compressing objects: 100% (2069/2069), done.
remote: Total 24757 (delta 3133), reused 5447 (delta 3101), pack-reused 19272
Receiving objects: 100% (24757/24757), 5.50 MiB | 7.97 MiB/s, done.
Resolving deltas: 100% (14407/14407), done.

~/scratch
❯ gix t organize             
 11:17:42 organize Error when handling directory "./gitoxide": Remote URLs must have host names: file://gh:Byron/gitoxide
Error: Failed to handle 1 repositories

I'm not sure if gitoxide can parse .gitconfig files right now, so this might be tricky to handle correctly...

edward-shen commented 3 years ago

git-config author here, we can definitely parse this information out of the config :)

Byron commented 3 years ago

Thanks for making us aware of this git-config feature!

As @edward-shen already clarified, it's not a problem of parsing but rather a problem of missing logic to further process certain git-config capabilities. Currently all we do is to read the single repository .git/config file and expecting the remote.url to be set.

In future as the git-config crate matures, I would expect this to be handled transparently or that additional utilities exist to make handling this case easier.

K900 commented 3 years ago

Yeah, so the problem (maybe? I'm guessing blind here) with that is the aliases are defined in the global ~/.gitconfig, not the repo's .git/config, so you now need two sources to resolve the URL correctly. That said, I might just poke it myself and see what happens this weekend.

Byron commented 3 years ago

That's one of two problems. The first one is the lack of a cascading config file interface at least for reading values, and the second is the lack of additional logic on top of certain 'special' configuration values, like file includes and…this one :D. Probably there are more.

That said, I might just poke it myself and see what happens this weekend.

Contributions are definitely welcome!