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.

[cruessler]

There are git config settings related to remote branches, among them remote.pushDefault and branch.<name>.remote. Is this relevant here?

https://git-scm.com/docs/git-config#Documentation/git-config.txt-remotepushDefault https://git-scm.com/docs/git-config#Documentation/git-config.txt-branchltnamegtremote

[extrawurst]

good point. then we should probably allow visualising what these configs are set to and allow changing them. and of course we need to start using them, at this point they are not respected by gitui

I still think we need to systematically support multiple remotes: add/remove and when I create a branch locally I need to know to which remote it should go to (or multiple even, does git allow that?)

my personal use case I'd like to cover is: adding remote with a PR branch, check it out locally, work with it, commit to it, push to it, delete it after.

[cruessler]

There is branch_upstream_remote to get the value of branch.<name>.remote. Does it make sense to start by using that instead of DEFAULT_REMOTE_NAME here?

https://github.com/extrawurst/gitui/blob/370aff5fcc316bf381c650942065c06ffb5eb76e/asyncgit/src/sync/remotes/mod.rs#L54-L82

https://docs.rs/git2/latest/git2/struct.Repository.html#method.branch_upstream_remote

[extrawurst]

@cruessler yes that would be a great start. could you look into that?

[cruessler]

@cruessler yes that would be a great start. could you look into that?

I’d like to do that if you haven’t already started working on a solution yourself!

[extrawurst]

@cruessler no I have not. would be really welcome if you could tackle this! If you need any support you can find me on discord

[cruessler]

What would be the expected behaviour of get_default_remote_in_repo? Is it supposed to return the upstream name the current branch has a remote configured for? This feels like a rather drastic change, so, as an alternative, we could introduce something like get_current_branch_remote and use it in some/all of the places we currently use get_default_remote_in_repo. But I feel I still lack a bit of context to suggest a specific solution. :smile:

Git itself does not seem to have a repository-wide concept of a default remote.

(Will join Discord next time, I’ve only now seen you mention it.)

[cruessler]

Adding someting like get_remote_to_pull_from and encapsulating the specific logic there seems also possible.

[extrawurst]

Everyone here please give #2156 a try, as this improves dealing with multiple remotes quiet a bit!

[extrawurst]

@RobertHana would you be able to build from source off of @cruessler #2156 to test if this fixes your problem?

[cruessler]

@extrawurst #2156 implements changes for push only so far.