search

fabioz / mu-repo

Tool to help in dealing with multiple git repositories
http://fabioz.github.io/mu-repo/
Other
295 stars 37 forks source link

Avoid changing the user-defined order of remotes when a clone hits. #70

Closed tarcisioe closed 2 years ago

tarcisioe commented 2 years ago

Mu changes the order of remotes when it hits one. This means that the order specified by the user is discarded whenever the remote that is hit is not the first. This can cause issues when the other remotes have, as an example, read-only mirrors of the same repositories that should be found on the first one in the list.

This pull request removes that behaviour and keeps the list unchanged during cloning.

nicoddemus commented 2 years ago

@fabioz to give a bit more context:

We are moving our private repositories to GitHub. When we do that to a repository, in Stash we move it to a new "project" called GHVAULT for backup purposes, so ESSS/etk is moved to GHVAULT/etk, and made read-only, after we have moved it to GitHub.

However, Stash creates an automatic redirection, so users that issue git clone esss.stash/ESSS/etk actually clone it from esss.stash/GHVAULT/etk.

So as we are moving some repositories, it happens that it is possible for a repository to be available in both GitHub, and Stash (due to the redirect), so depending on the order things are cloned, mu will apply this optimization and start cloning repos from Stash, instead of honoring the list in the configuration and clone from GitHub when that repository is available there.

Our initial take to fix this is to just remove this optimization, as we were very surprised that it would do that behind the scenes, but let us know if you think the current behavior is good and would rather introduce a way to instead disable it via some configuration.

fabioz commented 2 years ago

Seems fair ;)

Just applied.

nicoddemus commented 2 years ago

Awesome, thanks for the prompt merging. 😁

Would appreciate a new release if possible too. 😁

fabioz commented 2 years ago

@nicoddemus are you in a rush for a new official release with the fix?

I just noted I haven't setup github actions to do an automatic release in this project, so, I was planning on a new release only when I'm also able to do the proper github actions for that (probably doing a release on the push of a tag).

nicoddemus commented 2 years ago

@fabioz no rush, we can always workaround the problem, take your time.

Thanks again!

fabioz commented 2 years ago

@nicoddemus Just to note, I ended up doing the GitHub actions part (and a 1.8.2 release is now already available).

nicoddemus commented 2 years ago

Awesome, thanks Zaza!