Branchout Relocate

[fredcooke]

From time to time large organisations like to switch services such as:

bitbucket to github.com github.com to self hosted GHE gitlab.com to bitbucket

etc.

When that happens it's necessary to run some sort of command over the repo tree that corrects all of the repo URLs (assuming the repo names stay the same, usually fair). The approach I've used in the past has been something like this:

cd ~/branchout/<root-to-change> ; sed -i "s,ssh://git@bitbucket.someorg.com:1234/whatever,git@github.com:someorg," */*/.git/config

It's proposed that we add a new branchout command that takes one arg, being the new base and does some validation on it like this:

branchout relocate 'git@github.com/someorg'

And that the first thing that does is:

• read its own URL
• remove the existing prefix from its own URL
• place the new prefix on the remainder of its own URL
• validate that the URL is usable with some command (to be determined)

And then go about fixing the .git/config files in every repo, including the base one, with the same change. Ie,

.git/config
*/.git/config
*/*/.git/config 

Either with sed or git itself. I'd advocate sed for two good reasons and advise against it for one reason:

• sed is far faster than git to make this change
• sed takes care of all remotes at the same time, there are lots of legit reasons to have more than one remote in the same org in the same repo
• sed is not portable between BSD/CrapOS and Linux/WSL2 so this would need some sort of OS detection to behave properly

In either case, the presence of the .git/config file is a good indicator for trying to run a git command against a particular dir - many of the dirs won't have a .git directory, particularly /.git/config will not exist for all / dirs.

I'm going to have a crack at this, but @stickycode, how do you want it structured? A new command in the main file or a file of its own or what?

Cheers.

[stickycode]

The sed looks reasonable, off the top of my head I can't think of any situations where you would get ',' in the urls, so the comma separator is fine.

Agreed that sed will be significantly faster that running git remote set-url on every repository

OS detention is needed and will be helpful for some other things like yarn which behaves differently on Windows, sorting out the windows tests in travis would be really handy.

[stickycode]

relocate seems like a reasonable name

[fredcooke]

Comma is your standard, just used it at the time and copied it from then - good point though. However as you taught me, any character can be used - I suppose comma is as good as any other - I can't think of a reason not to use it, either.

relocate was your name, too :-D so of course you like it. Maybe copying git would be better, though? set-url? Not too bothered, as long as it's documented and self documenting, and fairly self explanatory, it doesn't really matter much.

So, OS detection first. I think I have access to all three OSes right now, so I'll see what I can find that works and doesn't require crazy dependencies. I might have something already in one of my old projects, actually.

[fredcooke]

Testing revealed a couple of scenarios that belong in a new ticket or PR or ignored entirely, but I'll document them here, for the record:

1. If some how not all repos have the same base clone URL, for example, mismatched case that is handled seamlessly by the git server in question, then the process will need to be run twice, the second time editing the BO root repo to have the alternate case version found in the repos that were not processed by the sed the first time. I don't think this needs fixing, the situation was broken and it would be wrong to make it loose-match IMO.

2. If the BO repo somehow already matches the target then nothing is done. Ditto, broken corrupt scenario, nothing to fix in BO, revert the URL in the BO root repo and run relocate.

3. If the repos are also renamed at the same time as being relocated branchout can't necessarily help with this and fetch/pull won't work. However there is a subset of cases that it'd be nice to support and that's an additional prefix to be applied to all repos within a BO tree, see #80 to follow that.

Closing this.