search

git-bug / git-bug

Distributed, offline-first bug tracker embedded in git, with bridges
GNU General Public License v3.0
8.15k stars 269 forks source link

Bridge: configurator should select which identity to use #642

Open GlancingMind opened 3 years ago

GlancingMind commented 3 years ago

Last time I tried, the GitHub bridge imported all bugs with my current user identity (not sure if this also applies to the other bridges). I think it might be better to use a at least a special "bridge" user for importing bugs. This way the user can see, that the bug was imported.

Other idea would be to support a "sync" status field, which contains a reference for each repository a bug was synced with. Then a user could be show a list if each synced repository contains the specific bug.

MichaelMure commented 3 years ago

Unless I'm mistaken, you only need a proper identity to export. That makes sense because you need to add your bridge credentials somewhere to interact with the remote bug tracker.

Maybe your point is that the bridge configuration wizard should allow to optionally not setup credentials? But that would only work with public repo.

GlancingMind commented 3 years ago

Oh I think we are talking about two different thinks. Let me clarify as my first post is a bit ambiguous. The problem I'm referring to is, that imported bug have my identity as author. This means, that those bugs appear to be written by me, but they might not.

Two possible solutions that I could think of:

  1. While importing bugs, identities are created for each participant. Maybe this identities could link to their public user profiles, to make sure, that each identity is unique. This is important, as the MichaelMure on GitHub might be a different individual then MichaelMure on GitLab. By attaching an identity to some public profile, it can be ensured that both identities are different. At least until both public profiles claim to be the same individual.
  2. Treat a bridge as an identity. As a bridge already requires a name for setup, this name could be used as a name for an identity. When importing bugs with the bridge, the currently used identity should be the one of the bridge. Then imported bugs will have the identity of the bridge as author instead of mine.
MichaelMure commented 3 years ago

While importing bugs, identities are created for each participant. Maybe this identities could link to their public user profiles, to make sure, that each identity is unique. This is important, as the MichaelMure on GitHub might be a different individual then MichaelMure on GitLab. By attaching an identity to some public profile, it can be ensured that both identities are different. At least until both public profiles claim to be the same individual.

That's how it should work. Isn't that what's happening for you?

I mean, an importer should create as much identities as needed to have the bug reflect the real history.

GlancingMind commented 3 years ago

When I import the issues of my git-bug fork, they appear as my currently used git-bug identity TestUser. See this issue: https://github.com/GlancingMind/git-bug/issues/20 Notice the author of the Bug, which is TestUser instead of GlancingMind. image

Somehow the GlancingMind identity is replaced by the TestUser identity as git-bug user ls don't display my GitHub identity.

6ac33cd Michael Muré (MichaelMure)
94c90ef timbkr (timbkr)
723b0b4 TestUser
a76df02 Cláudio Silva (claudioantonio)
7d8b135 LenaNoctua (LenaNoctua)
MichaelMure commented 3 years ago

That's definitely a bug. Is that happening as well with the termui?

GlancingMind commented 3 years ago

Yes, the termui also displays TestUser.

MichaelMure commented 3 years ago

WTF :-D

In that case that should be easy to reproduce/debug but what I'm confused about is that our tests should protect against something as obvious.

GlancingMind commented 3 years ago

~Ah. I know where TestUser originates from. It is also used within my git config user.name.~

~Update: Somehow I got it to work. But I'm not convinced. I'll investigate some more.~ ~Update: I have the feeling, that I never got it to work properly :grimacing:~ Update: I think I know where this behavior comes from. Will investigate further.

GlancingMind commented 3 years ago

Okey got the error. I'll try to explain what happens: The github bridge adds a Metadata field (github-login) to currently used identity. (By doing so the bridge assumes, that my current identity matches the user of my github account.) While importing issues, the bridge checks, if an identity already exists. Otherwise the identity will be created. This is done via a cache lookup, of an identity with the github-login matching those of the issue author.

Problem: The bridge has assigned my current identity (TestUser) the github-login metadata and so the lookup will return the TestUser identity, instead of creating another identity with the name Sascha (my real GitHub identity).

How to solve this problem?

  1. Check if the identity returned from the cache has the same name as the current identity. If the names don't match, create a new identity from the imported issue otherwise reuse the already existing identity. This introduces another error, as there are now two identities with the same login metadata. The identity used when bridge configure was invoked (TestUser) and the new imported identity from the issue (Sascha).
  2. Make sure, that the git config user.name matches the name of the GitHub identity. This will certainly become a problem, when multiple bridges are used. E.g. My GitLab account might not have the same username as my GitHub account, yet I have to choose one under which git-bug create bugs.
  3. The bridge should never assign the github-login metadata field to the currently used identity. Then all issues should always have the proper author. Though the user has to make sure, to correct the git config user.name.

  4. This is not a bug. My currently currently used identity is an aggregate of all my other identities, which just might have different usernames. When importing bugs, all bugs of my other identities are displayed via my "git-bug" identity. When I create a bug and export to GitHub and GitLab, both should then have the name used for the respective service. Suppose that I have the following usernames:

    GitHub -> Sascha GitLab ->Foobar git-bug -> TestUser

Within git-bug, the bugs of my other identities are displayed as "TestUser". After exporting the bugs to GitHub, the author should be "Sascha" and analog for GitLab "Foobar". I think this is a fitting model. Maybe requires some explaining in the ReadMe?

~ I hope that this wall of text is understandable. :grimacing: ~

MichaelMure commented 3 years ago

The github bridge adds a Metadata field (github-login) to currently used identity. (By doing so the bridge assumes, that my current identity matches the user of my github account.)

Correct. This happen at the end of each configurator, with this common piece of code: https://github.com/MichaelMure/git-bug/blob/87b97ca4b2f39240c698596ac14a6d3532f6363d/bridge/core/config.go#L22-L33

Problem: The bridge has assigned my current identity (TestUser) the github-login metadata and so the lookup will return the TestUser identity, instead of creating another identity with the name Sascha (my real GitHub identity).

Ok so the current identity is used as the identity matching the remote account. However, that identity doesn't replace all the others like I initially thought from your report.

So, to me this is more a UX issue. You got confused as to why the github identity got mapped to your current git-bug identity. That's a fair issue but what I wonder is, would have you been confused as well without your docker setup?

There is two scenarios for the bridges:

Scenario 1:

Scenario 2:

If you look at the code I linked above, it address those two cases. Either the existing identity is mapped, or a new identity is created.

Now that doesn't mean it's perfect, and there is probably more way to use git-bug.

So what could be done:

GlancingMind commented 3 years ago

However, that identity doesn't replace all the others like I initially thought from your report.

Oh I didn't even consider this, as the imported repository contains only issues created by myself. :-)

That's a fair issue but what I wonder is, would have you been confused as well without your docker setup?

Probably I wouldn't have noticed, as my git config user.name would likely match my GitHub identity. But I can think of a case in which this might still have happened. E.g. I have my git-bug fork on GitHub and on GitLab. Suppose that I have the following usernames

GitHub -> Sascha GitLab -> Foobar

My git config user.name can only match one of both services. Let's say it matches Sascha. Now importing bugs via the GitHub bridge will result into bugs created by me, with Sascha as author. Next I import via the GitLab bridge the bugs from GitLab. Those bugs who are created by me, will be displayed with Sascha as author. But if I wouldn't know now better, I would expect those bugs to be displayed with Foobar as author.

Well I know now better and the design of git-bug makes perfect sense. :+1:

  • try to be smart and see if the name of the git-bug identity match the github one ... but that would probably introduce more weirdness and confusion

I agree, this seems to be not the right solution.

  • ask the user for confirmation before mapping the current identity (scenario 1), otherwise create a new identity

This sound fine to me.

Maybe the git-bug user ls command could be improved to make thinks more clear. E.g. following output

6ac33cd Michael Muré (MichaelMure)
94c90ef timbkr (timbkr)
723b0b4 TestUser **(This is you)**
|> GlancingMind (on GitHub)
|> Foo (on GitLab)
| ...
a76df02 Cláudio Silva (claudioantonio)
7d8b135 LenaNoctua (LenaNoctua)

Part of my confusion is probably also due to that I thought, my GitHub identity would be a separate one. E.g. similar to this:

000000 Foo (Bar)
6ac33cd Michael Muré (MichaelMure)
94c90ef timbkr (timbkr)
999999 Sascha (GlancingMind) 
723b0b4 TestUser **(This is you)**
|> you are also, 999999 Sascha (GlancingMind), on GitHub
|> you are also 000000 Foo (Bar) (on GitLab)
| ...
a76df02 Cláudio Silva (claudioantonio)
7d8b135 LenaNoctua (LenaNoctua)
MichaelMure commented 3 years ago

ask the user for confirmation before mapping the current identity (scenario 1), otherwise create a new identity

.. it is then.

Also agree on the user ls command, there is many ways to make it less crappy. The good balance is a bit tricky to find though.

GlancingMind commented 3 years ago

Or what could also work, print a message similar to this one after the bridge was configured.

Your git-bug identity "TestUser" has adopted your GitHub identity "Sascha (GlancingMind)". Just for information: Bugs created by your GitHub identity "Sascha (GlancingMind)" will be displayed under your git-bug identity "TestUser".

GlancingMind commented 3 years ago

Also agree on the user ls command, there is many ways to make it less crappy. The good balance is a bit tricky to find though.

Let me know, if I should create dedicated issues out of my given example.

MichaelMure commented 3 years ago

A message works but then the user has no way to fix the situation if it's not what he expect. Might as well add the prompt and select the right thing to do.

So, if there is a current user: Is your current identity TestUser the one you want to associate with $login? [Y/n]

Let me know, if I should create dedicated issues out of my given example.

Issues are good, PRs are even better ;) But yes we can discuss first about what to do.

GlancingMind commented 3 years ago

Issues are good, PRs are even better ;)

Sure. Maintainers time is precious :D

github-actions[bot] commented 3 months ago

This bot triages untriaged issues and PRs according to the following rules:

To remove the stale status, you can:

github-actions[bot] commented 1 week ago

This bot triages issues in order to help the maintainers identify what needs attention, according to the following lifecycle rules:

This bot will not automatically close stale issues.

To remove the stale status, you can:

To avoid automatic lifecycle management of this issue, add lifecycle/frozen.