by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 12:06

    MichaelMure on gogit-repo

    repo: fix gogit clock path repo: smaller interfaces repo: test both plain and bare,… (compare)

  • Sep 22 18:42

    MichaelMure on master

    Update README.md (compare)

  • Sep 21 21:17
    6543 commented #394
  • Sep 21 14:03
    AtomToast commented #453
  • Sep 21 14:00
    zdenek-crha commented #457
  • Sep 21 13:04
    MichaelMure commented #453
  • Sep 21 12:09
    MichaelMure commented #453
  • Sep 21 11:55
    AtomToast commented #453
  • Sep 21 10:27
    MichaelMure commented #453
  • Sep 21 09:30
    zdenek-crha commented #453
  • Sep 21 09:18
    MichaelMure commented #453
  • Sep 21 09:14
    zdenek-crha commented #453
  • Sep 17 04:46

    dependabot-preview[bot] on go_modules

    (compare)

  • Sep 17 04:46
    dependabot-preview[bot] commented #452
  • Sep 17 04:46

    dependabot-preview[bot] on go_modules

    build(deps): bump github.com/xa… (compare)

  • Sep 16 22:52
    AtomToast commented #453
  • Sep 16 15:42
    MichaelMure commented #453
  • Sep 16 15:39
    MichaelMure commented #454
  • Sep 16 15:30
    MichaelMure commented #455
  • Sep 16 15:11

    MichaelMure on remove-legacy-identity

    identity: remove support for le… (compare)

matrixbot
@matrixbot
strk it looks like it's git-bug ls behaving differently if output is a terminal or not
strk because the little squares are still colored, but hash and status are not
strk (same thing when piped to head)
Michael Muré
@MichaelMure

git bug log

yeah, could be nice to have

the CLI commands are really meant for scripting or tooling integration
I think having no color when piping is the correct behavior
try ls | less and you will have the same thing
git-bug has some inconsistencies though, there should be zero colors when piping

what would you think about status:open being the default filter for bug list ?

I'm torn. On one hand, yes it's what people expect, on the other hand why does "ls" without selector should have a filter ? And so how would you list everything ?

cheshirekow
@cheshirekow

what would you think about status:open being the default filter for bug list ?

I'm torn. On one hand, yes it's what people expect, on the other hand why does "ls" without selector should have a filter ? And so how would you list everything ?

Just a random note: gnu ls without a selector does not show dotfiles. You show everything with -a/--all.

Michael Muré
@MichaelMure
That's a good point
Daniel Lidström
@dlidstrom
I've recently discovered git-bug. It is very neat, thanks for working on this. I'm interested in the long term goals and would like to keep up-to-date, but not on a daily basis. For example, is there a plan to be able to work in the webui? If so, are there a GitHub issue that I can watch? I am missing milestones that explain what will be coming next, to know what to expect and how much to rely on this project. Thanks!
Michael Muré
@MichaelMure
@dlidstrom if you mean "being able to edit bugs like you would on github", yes, that's the plan, but someone need to work on that to make it happen. There is a bunch of issues about the planned features but the information is a bit scattered. Please understand that it's a side project for me and if I spend my time on doing project planning I wont do anything else. Also, what is actually developed in practice is what people coming forward to help are working on. I can make the best plan but it won't be accurate.
matrixbot
@matrixbot
strk dlidstrom: there is a GUI, I understand (maybe not so advanced as you would expect) - did you try that ?
strk I think what people are currently doing is keepign git-bug as form of backup, "syncing" the git-bug held bugs with a GUI of their choice among the supported bridges (github/gitlab/can't-remmeber-what-else)
strk I'd love to do that as well but would need the ability to "sync" that bug database with multiple bridges, which I belive is currently unavailabel as a feature
strk and, at the end, I'd need a bridge for Trac and one for Gitea to be really happy about that :)
strk but I don't have the time to deal with it myself, so it won't probably happen until I do...
strk dlidstrom: do you have the capability to help with implementing some of what you need ?
Daniel Lidström
@dlidstrom
I will be more than happy to use git-bug, but I can't commit to working on it. Anyway, I realize this is a side project and I am not asking you to spend time on planning. I just thought you could share any plans you already have. Thanks for your replies.
matrixbot
@matrixbot
strk I didn't contribute either, yet, just some comments about commandline interface :)
Michael Muré
@MichaelMure
@strk you can setup multiple bridges but support for transfer from one to another is limited
matrixbot
@matrixbot
strk limited by inability to determine a mapping between bugs, right ?
strk I kind of remember something like that
Michael Muré
@MichaelMure
Actually bugs are tagged with the origin and there is a check somewhere preventing bugs from one bridge to be pushed to another
This is temporary until a better system exist to prevent a mess
The biggest problem is that to push a bug, you need a credential for all the identities that participated
Also, it's generally untested
This could be grown into a real way to transfer bugs from one tracker to another but there is some road left
matrixbot
@matrixbot
strk credentials for all identities sounds indeed painful
Michael Muré
@MichaelMure
Note that it's not a git-bug limitation, if you want to add a comment as someone else on github, you need his/her credentials
Eventually this could be a online service w
matrixbot
@matrixbot
strk yes, I understand this
strk maybe not all "sinks" have this "limitation"
strk although I'm not sure (some "super-account"?)
Michael Muré
@MichaelMure
... that collect those credentials as OAuth session and perform a one time transfer
Yeah, I suppose some special cases exist
Why do you want that ?
matrixbot
@matrixbot
strk as admin of a Trac instance
strk I was thinkign I might know what I"m doing
strk but maybe not :)
strk synchronizing bugs in this way would effectively require having all bug authors EXIST on all "mirror" platforms
strk not ideal
strk oh.. identity
strk what a pity that proper federated identity failed to be honoured (yet)
Michael Muré
@MichaelMure
maybe one day :)
matrixbot
@matrixbot
strk I'm still pushing OpenID, but seems to be something people urge to bury
Michael Muré
@MichaelMure
the only real way is git-bug identities
(joke, if that's not obvious)
matrixbot
@matrixbot
strk I love the OpenID idea (your identity is your web presence)