pull on clone with multiple remotes yields Error: 'git: inconclusive remotes' and stuck on 'Pull: preparing ...'

[RobertHana]

Describe the bug
I cloned a repo and added a 2nd remote. Using gitui, I issued the Pull[f] and it yielded 'Error: git: inconclusive remotes' and eventually got stuck on 'Pull: preparing ...'.

To Reproduce
Steps to reproduce the behavior:

1. Pull[f]
2. See error, and hit return to close and get stuck on next error with no further way to close.

Expected behavior
I expected the pull to pull from the tracked remote, at least.

Screenshots
I don't think I need a screenshot, do I?

Context (please complete the following information):

Software version

gitui 0.19.0

Operating system

macOS 11.6 (Darwin 20.6.0)

Compile time information

• Profile: release
• Target triple: x86_64-apple-darwin
• Family: unix
• OS: macos
• Architecture: x86_64
• Pointer width: 64
• Endian: little
• CPU features: fxsr,sse,sse2,sse3,ssse3
• Host: x86_64-apple-darwin

Environment variables

SHELL=/bin/bash
EDITOR=vi
GIT_EDITOR=vi
VISUAL=vi

Command-line

gitui --bugreport 

Additional context
If you aren't familiar with how to add multiple remotes:
% git remote add remote1 {git-remote-url1}
% git remote add remote2 {git-remote-url2}

[extrawurst]

hm interesting so you have no remote called origin? gitui expects there to be one currently. you are right, for pull/fetch we can figure it out by checking the tracking branch but for a push of a brand new branch we would have to ask what remote you want it to go to, this is another feature we currently miss.

does it work if you name one origin?

[RobertHana]

okay i renamed it origin and i now get the error:

fetch failed:
git error:config value
'branch.feature/ESPNG-1471-Add-override-flag-indicators-to-tabs-in-Settings-and-Assumptions-when-something-is-overridden.remote' was not found; class=Config (7); code=NotFound (-3)

Just in case the problem was the slash in our branch names (see next comment)

[RobertHana]

I tried this on a different cloned project that had 2 remotes, but the checked-out branch was master. I renamed one remote origin and did a pull and got the error:

fetch failed:
git error:config value 'branch.master.remote' was not found; class=Config (7); code=NotFound (-3)

[cherio]

Same here. I do not have "origin" remote.

The application is awesome BTW. Fast and small. I'll be keeping an eye on it and hopefully it goes mainstream.

[extrawurst]

somewhat related to #1306

[augustsaintfreytag]

This is still a pending issue, it’s a strange decision to not support any other remote identifier than origin. If multiple remotes can not be supported at this time, at least allow configuring the assumed default remote so it can be changed.

[extrawurst]

its not so much a decision but a lack of implementing that feature. and implementing to configure something that would be obsolete as soon as the proper remote selection UI is implemented made no sense.

[augustsaintfreytag]

If an interface to select custom remotes is right around the corner, sure, I just think this is a somewhat glaring oversight in the current version. I’ve looked through a number of issues here and it seems the intended behaviour right now should behave as (1) look for origin, if not found (2) use the first remote found. If this worked, the remote used would be at worst indeterminate but it should never crash with “inconclusive remotes”.

My personal suggestion to triage this:

1. If time to completion for an interface to select remotes is low — as in, weeks away — we can all wait for that feature. If that allows for any remote to be picked as a default and origin as an assumed default can be ousted, all these issues can be closed.
2. If time to completion is high — more than a few weeks — the majority of these issues can be solved by just lifting the assumed default origin out to a configuration file. gitui already uses *.ron files to enable customisation. Alternatively, even as a workaround, it could read an environment variable like GIT_DEFAULT_REMOTE. I believe even picking any would bet better than the current behaviour of bailing with “inconclusive remotes”.

I don’t have a good working relationship with Rust and don't want to intrude into your implementation but I can see pub const DEFAULT_REMOTE_NAME: &str = "origin" already exists but origin is still used as a hardcoded value in most places.