pull, push: try reading git-bug.remote config value before defaulting to 'origin' when no explicit REMOTE argument

[wahern]

No description provided.

[MichaelMure]

Neat, thank you!

I like the idea, but if I get that right, git-bug.remote is a brand new config entry that the user would have to setup, correct? In term of usability, it's not ideal.

What about instead do something like cfg.ReadAll("remote.") and parse the available remote, directly from the normal git config? It does get murky if there is more than one remote, but that should be a fairly rare case in practice. Maybe we can use git-bug.remote only in that rare case?

[smoyer64]

If there's more than one remote, perhaps let the user select one? We'll have to guide the user to picking identities eventually (especially when there are keys involved.)

[wahern]

My intention behind this was to make it easier to push git-bug data to a separate, standalone repository, and to reduce the risk of accidentally pushing to one that I wanted to keep clean.

The inception of this idea comes from running into the user initialization issue--you can't pull into a repository without first creating a new user. See #1072. Which means I either have to manually delete[1] that new identity after the first pull into a newly cloned repository, or I end up with a new user for every repository I want to manage bugs in.

I wouldn't mind taking a shot at #1072, but that's much more involved and I wanted to just get to a place where I could try out git-bug for awhile before fully committing to it; I didn't want to have any remnants in my central repository if things didn't work out.

Regarding asking the user: At least for my open source projects, my working repositories usually have at least two upstream remotes: my own hosted server and GitHub. Similarly, for this particular project there's also at least two remotes counting the separate git-bug repository (standalone or not). Interactively asking the user every time would be annoying for my workflow. And if it kept state so it only needed to ask once, that's state I'd like to be able to manually control, just like with regular git. If you mean you would prefer a patch to include the ability to ask if git-bug.remote isn't yet explicitly set, rather than defaulting to origin, that makes total sense and I'd be happy to try that.

[1] I wasn't actually able to fully remove an identity from a repository. I can delete the identity from .git/refs/identities, but that still leaves around orphan objects in .git/objects which I couldn't figure out how to remove with git prune or git fsck. I don't think these objects would get pushed up. But once they did (e.g. by accident) you're back to square 1 in the sense that now your upstream repository will have been polluted with no simple way to remove the objects without recreating the repository.

[MichaelMure]

@wahern as you will see in #1072 , #1003 , the solution for that problem is different from what you suggest here.

That said, your point about having multiple remote for different purpose makes sense. In that situation, the user is very likely to always interact with the same remote for bugs, so having a way to bake that is relevant.

There is really two three different problems here:

• user want to always interact with the same remote
• there is only one remote, but it's not origin
• there is more than one remote, we need to pick one

What about:

1. List the remotes (with something lke cfg.ReadAll("remote.")). If there is only one, pick that. If there is none, fail.
2. We have more than one remote --> if git-bug.remote exists, use that.
3. Print an error indicating we need the user to choose which remote explicitly, or set git-bug.remote --> clean and easy fail, and the user is guided towards a more sticky solution

Do you think you could implement that?

[MichaelMure]

I wasn't actually able to fully remove an identity from a repository. I can delete the identity from .git/refs/identities, but that still leaves around orphan objects in .git/objects which I couldn't figure out how to remove with git prune or git fsck. I don't think these objects would get pushed up. But once they did (e.g. by accident) you're back to square 1 in the sense that now your upstream repository will have been polluted with no simple way to remove the objects without recreating the repository.

If think you are looking for git gc to remove those unreachable objets. In any case, they should never be pushed (as not enumerable).

[sudoforge]

@MichaelMure said:

1. List the remotes (with something lke cfg.ReadAll("remote.")). If there is only one, pick that. If there is none, fail.
2. We have more than one remote --> if git-bug.remote exists, use that.
3. Print an error indicating we need the user to choose which remote explicitly, or set git-bug.remote --> clean and easy fail, and the user is guided towards a more sticky solution

I think the git-bug.remote should be preferred, no? So the order of operations should be:

1. If git-bug.remote exists, use that.
2. If not, list all remotes. If there is a single remote, use that. If there is more than one remote detected, prompt the user to select a remote and use the selection. Whatever remote is used should be set as the value for git-bug.remote automatically.

This provides a pretty seamless workflow. An informational message could be logged if git-bug.remote is updated, I guess, to provide that information to the user. I don't think erroring out and making them manually set a value makes sense in most cases, since we'll (likely) already have a remote.origin.