git fork [repo] should add upstream if it doesn't already exist.

[zaquestion]

Similar to: #78 expected outcome is the same

[tydavis]

This may be accomplished by using set-url option like explained here: https://blog.github.com/2015-07-29-git-2-5-including-multiple-worktrees-and-triangular-workflows/#improved-support-for-triangular-workflows

[bmeneg]

I'm not sure if I understand the expectation here: today, when a lab fork [repo] is performed, both origin and upstream is added, the first is added by the git clone command itself and the later is added by lab. This is the default behavior for when forking a project from outside a git repo. When forking from origin it doesn't really makes sense to add upstream if origin is the actual upstream project in gitlab, does it?

[tydavis]

This is to work with/around the issues which copy-paste commands have wrought. Nearly all documented / blogged-about / etc operations are set to run on origin. By making sure that origin is the personal fork of the repo, there's less of a chance that an accidental merge will be made against upstream's representation.

Though, this also goes against most other tools' methods (like hub) where a forked repo uses the username in order to represent the local fork (e.g. tydavis instead of origin)

[bmeneg]

Ahh I see! So the idea was to rename origin to upstream when the user forks the project pointed by origin.
Thanks for the clarification 👍

The issue I see with this approach is: users getting pretty confused wondering "what happened" to their remotes "out of sudden".
It would be necessary to also update all the branches tracking origin remote branches to then track upstream instead.

IMHO I don't think that lab should try to be "too smart" about such things, users should keep track of their own remote names and change as they please. I would vote for not implementing it and let things as they are.

[bmeneg]

Considering this issue is from 2017, the behavior didn't change and that in general it doesn't really look like a good approach, I'm going to close the issue. But please, feel free to re-open it.