search

sifive / wit

Workspace Integration Tool
Apache License 2.0
23 stars 13 forks source link

Remove dependency on `origin` remote #203

Open richardxia opened 4 years ago

richardxia commented 4 years ago

It is unclear to me why we are relying on the existence of a remote named origin. I suggest that we do not assume that a remote named origin is always present or that it has any special meaning.

I also suggest that we mimic Git's own treatment of origin, which is non-special. For example, the ability of git checkout foo to automatically perform git checkout -b foo origin/foo is actually not specific to origin, but it actually searches all remotes and only does the expansion when branch name is unique: https://git-scm.com/docs/git-checkout#_description

We should make sure that we print the appropriate error messages for any commands that are dependent on having at least one remote.

mmjconolly commented 4 years ago

Is this about letting people rename their remote? Or about wit not knowing any remote names?

Or is it the issue that if they add a very similar remote to the initial origin it'll have all the same branch names and since we aren't explicit enough about origin it can't figure out which to use?

richardxia commented 4 years ago

Or about wit not knowing any remote names?

This.

I think I ran into a weird error message with Wit when I had a Git repo without any remotes, since I was trying to test something locally without having pushed a new repo I created out to GitHub yet.

It was either that, or I had a scenario where I had two remotes that I manually set up, and I deleted the origin remote because I wanted to force myself to explicitly specify which remote I wanted to push a branch to instead of accidentally letting my muscle memory push a branch out to the origin remote.

jackkoenig commented 4 years ago

I think the reliance on a remote named origin was more about the fact that a remote existing is baked in to a lot of the implementation. I agree it's not good but it simplified things early on.

mwachs5 commented 4 years ago

Yes, concretely if during your workflow you decide to change the dependency to something you have checked out a new version of, and locally you are calling it, say mwachs5, and then you delete the origin to avoid as you say messing up and pushing to origin instead, you can run into this issue.