Avoid destructive language-repo origin updates

[scbedd]

I'm chasing a hidden GitProcessException in #9208 . I have a hunch that that combined with a failure to properly get the target repo is causing git to get into an irreconcilable state. When that happens, and git remote set runs, it escapes the <languagerepo>/.assets/sliceId/ folder because there isn't a real git repo initialized there.

when that occurs, and we still invoke git remote set-url, that'll override the language repo origin. @alzimmermsft this should at least reduce the impact when something goes wrong. I'm still chasing the real origin of it all though.

[alzimmermsft]

Just a random thought here given the popularity of using the remote name origin, have we thought about using something unique for the azure-sdk-assets remote? Something like assetsremoteorigin, or really anything else unique, so it doesn't accidentally clobber existing origin remotes?

[benbp]

@alzimmermsft I think that's a good idea, adding a little resilience (also makes it easier to realize if you're actually operating in the assets directory vs. the repo root when mucking around)

[benbp]

Thinking about it, adding handling to migrate existing asset clones to a new remote within the tool is arguably not worth it (though it would be a pretty small task).

[scbedd]

Thinking about it, adding handling to migrate existing asset clones to a new remote within the tool is arguably not worth it (though it would be a pretty small task).

I think if we begin explicitly specifying an origin in all of the commands, we should be able to transition to using something not the default origin.

That being said once I understand #9208 (task for later today) I think this issue should either disappear or be seriously ameliorated.