git-plus icon indicating copy to clipboard operation
git-plus copied to clipboard

Any way to ignore remote sources and choose a "default"?

Open chenasraf opened this issue 9 years ago • 6 comments

I have 3 remotes for my git repo:

  • origin
  • heroku-staging
  • heroku-production

I'd like to automatically select "origin" so I don't get the intermediate modal that lets me choose every time. This should be relevant to one project. Is that achievable?

chenasraf avatar Dec 21 '15 08:12 chenasraf

I can't think of a simple way to do this.

  1. My first thought is to assume the first remote selected in the project is the default but that would lead to problems.
  2. Another way is to have users add extra git-plus related options to the repo's gitconfig. That's less messy although I'm not sure how people may feel about that.
  3. Lastly, there could be a package command to set the default and another command to push to default. I'm iffy on having a pair of commands for this.

Of these I'm leaning more towards option 2. What do you think?

akonwi avatar Dec 22 '15 04:12 akonwi

I like option 2 better too, but how about a CSON file instead? Something along the format of:

'/Users/myuser/Dev/projectDir':
    'remote-default': 'origin'
    # other configurable stuff in the future

This could be accessible from the package settings and command palette (same way color-tabs-regex does it for example)

chenasraf avatar Dec 22 '15 10:12 chenasraf

Oh that's even better. The next two priorities I have are allowing support for non-ssh users and showing diffs during commits. If you want to take a stab at implementing this, that would be great

akonwi avatar Dec 23 '15 22:12 akonwi

I'm not really experienced with atom packages, but I'll give it a go. :) :+1:

chenasraf avatar Dec 24 '15 16:12 chenasraf

:+1: for the feature request, and option 3 in my opinion is better because it's more atom-y, in the sense that commands are so easily accessible and easy to find through the command palette. But option 2 works as well :) Any update on this feature being implemented?

orensol avatar Jun 21 '16 18:06 orensol

@orensol I haven't picked this up yet. You make a good point about option 2 being more atom-y. Whenever this gets picked up, that should be the route taken and we can leverage atom's ability to manage state

akonwi avatar Nov 04 '16 18:11 akonwi