i must be missing something about remotes

[pjv]

i love the idea of making git more human and codifying a set of good practice conventions into a tool like this (and like the mac GUI), but i think i must be missing something basic about the implied workflow, or i am trying to apply it to a use-case that is outside of the domain it is trying to address (or i'm a dope).

the way that i usually set up to contribute to someone else's open source project is to:

1. clone their repo as origin on my local machine
2. fork their repo on github
3. add my fork as an additional remote to my local repo

then i create feature branches on my local machine and push them to my github fork and submit pull requests to the owner while also being able to fetch/pull from the owner's repo to keep up with their changes.

if i understand it right, legit is only intended and optimized for working with a single remote (i.e. my fork on github). so in the scenario above of contributing to someone else's project, how do i keep up with their changes?

i know that i can add an additional remote and just do what i always do outside of legit, but is this something that legit is not intended to address, or am i missing something?

any explanation or pointer to where this is already discussed would be very welcome.

[kennethreitz]

The beauty of legit is that it's fully supplementary to the standard commands.

If you need to pull from another remote, than do so :)

[pjv]

so in other words, i am not actually missing anything and legit is really designed to be used for single remote development -- i.e. it's meant for working more on my own stuff than collaborating with others.

sorry if i am being obtuse -- i am just trying to understand the big picture.

so if i want to use legit for a collaborative project like i outlined in my original comment above, and given that by default it works on the first remote, i should clone my fork first and then add the owner's repo as an additional remote and then when i want to fetch/pull from the owner's repo i do that with standard git commands. ya?

[kennethreitz]

Actually, someone just sent a pull request that allows you to do this:

$ git config legit.remote myfork

And it'll use that remote instead :)

It hasn't been released yet though.

[david-forever]

Has this change been merged?

I have two remotes:

(venv)~/git/whatever-proto1{master} $ git remote -v
heroku git@heroku.com:whatever-proto1.git (fetch)
heroku git@heroku.com:whatever-proto1.git (push)
origin git@10.10.1.113:whatever-proto1.git (fetch)
origin git@10.10.1.113:whatever-proto1.git (push)

legit publish

(venv)~/git/forever-proto1{master} $ legit publish

• master (published)
  sprint1 (published)
  sprint2 (published)
  sprint3 (published)
  sprint4 (published)
  sprint5 (published)
  test_sprint1 (unpublished)

Unfortunately, legit publish refuses to push to origin no matter what I've tried including:

git config legit.remote origin

and

git branch --set-upstream sprint1 origin/sprint1

As it stands, legit publish seems unusable with this configuration or am I missing some git command to tell legit which remote to use?

Thanks!

[weakish]

This issue should have been fixed in recent versions of legit.