sociomantic-tsunami
check for github upstreams in remotes/{upstream,origin}
Before erroring with Error: Can't find 'hub.upstream' config key in git config. Read the man page for details., see if the hub.upstream can be derived from the remote named 'upstream' or 'origin' (in that order?).
This will facilitate use by people new to git-hub but not new to github.
On Tue, Jul 22, 2014 at 01:12:06PM -0700, Paul Jimenez wrote:
Before erroring with
Error: Can't find 'hub.upstream' config key in git config. Read the man page for details., see if the hub.upstream can be derived from the remote named 'upstream' or 'origin' (in that order?).This will facilitate use by people new to git-hub but not new to github.
I personally believe that's guessing too much. Is not uncommon at all to
have your personal fork as origin (that's how you usually have it if
you use the triangular workflow). If your fork is mistaken for upstream,
then, in the best scenario, everything will break in more mysterious
ways (worse case scenario is you'll push things to the wrong repo).
What do you think?
The variability around where origin points is why it should look for an 'upstream' remote first, if one is defined. I think I'd rather have it guess wrong and have it tell me how to fix it than always have to fix it. For example what if instead it said:
Warning: no upstream repo configured. Falling back to pjz/git-hub ; if this is not the correct upstream repo, set it using 'git config hub.upstream <reponame>'
It can use a couple of heuristics to try and find the right upstream also:
- forks don't usually have issues in their issue trackers, if they have issue tracking enabled at all
- upstreams are often (usually?) not forks of any repo - github's network graph shows this, but I don't know if that data is available via API
On Wed, Jul 23, 2014 at 05:45:39AM -0700, Paul Jimenez wrote:
The variability around where origin points is why it should look for an 'upstream' remote first, if one is defined. I think I'd rather have it guess wrong and have it tell me how to fix it than always have to fix it. For example what if instead it said:
To be happy you should just use git hub clone instead, that will set
up hub.upstream for you.
Warning: no upstream repo configured. Falling back to pjz/git-hub ; if this is not the correct upstream repo, set it using 'git config hub.upstream <reponame>'
By the time this warning is shown, you might have committed to the wrong repo, which I find unacceptable.
What it could be done is suggest for a configuration, look for the remotes and print a message like this instead:
hub.upstream is not defined, but a {upstream,origin} remote was found,
so maybe you should set it to UPSTREAM_NAME (git config hub.upstream UPSTREAM_NAME). See the manual for more details.
It can use a couple of heuristics to try and find the right upstream also:
- forks don't usually have issues in their issue trackers, if they have issue tracking enabled at all
- upstreams are often (usually?) not forks of any repo - github's network graph shows this, but I don't know if that data is available via API
Yes, I thought of doing that (looking for the parent of the fork, if what we found is a fork). All this is still guess work, so I don't want to silently assume something (or even issuing a warning). You should never assume! https://www.youtube.com/watch?v=KEP1acj29-Y#t=36s
I would accept patches to improve the error message and make a smart
guess of how the user wants to configure its hub.upstream, but is not
something I'll be doing anytime soon because I don't consider it
particularly necessary (is only useful when you want to "convert" an old
clone not done by git hub clone) and there are a lot of more useful
things to implement first than this :)