git remote add upstream could be confused with push --set-upstream in Remotes section

[BenGitsCode]

I'm curious as why our instructions have them adding the remote singularly and not setting the upstream on a push.

Is there a pedagogical purpose to doing this (i.e. here's remotes in a nutshell and how to associate your local branch with a remote branch) but githubs instructions for connecting new local repos to remotes / creating repos always suggest the "set upstream on initial commit convention—and the developers will see that a lot.

I can see pedagogical value in starting with just adding remotes, and building up to what remotes and upstreams are, but it just struck me as unexpected.

I guess what I'm asking is would it grok easier with the developers if we called that fork or my-fork or something, to show that the remote name is just a variable we can change and that upstream is a convention.

This ties into #10 but I'm not clear on the consensus.

[jrhorn424]

@BenGitsCode What are your thoughts about teaching remotes only when they're needed?

[BenGitsCode]

@jrhorn424 I'm torn. I prefer the idea of trickling git details in only as they need them—but remote mismatches due to not forking often plays that hand for us sooner, as we detangle the problem for them.

If we took that approach, we would need to be miltant about walking them through forking and cloning. If we could do that, and omit remotes for now, I think it's less for them to take in at once (which is good with git) but we would need to be more general in our explanation of local and remote repos. Explaining that without remotes strikes me as tricky.

I like the idea, I'm not sure how to implement it.

Do you mean remove the remotes section and only teach it as it comes up instead?

[gaand]

Setting a remotes url is part of the fix to the clone not fork. It's probably good if they've seen it.

[MicFin]

Could close and reference from Issue #10