Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Apr 11 22:17
    rng-dynamics commented #631
  • Apr 11 22:15
    rng-dynamics commented #631
  • Apr 11 22:11
    rng-dynamics commented #631
  • Apr 11 22:11
    rng-dynamics commented #631
  • Apr 11 22:09
    rng-dynamics commented #631
  • Apr 11 22:04
    rng-dynamics commented #631
  • Apr 11 20:11

    rng-dynamics on comment-edit

    Fix ID string in order to find … (compare)

  • Apr 11 18:37
    rng-dynamics commented #629
  • Apr 10 21:07
    rng-dynamics commented #585
  • Apr 10 21:06
    rng-dynamics commented #629
  • Apr 10 07:59
    MichaelMure commented #630
  • Apr 10 07:54
    MichaelMure commented #629
  • Apr 10 07:52
    MichaelMure commented #625
  • Apr 10 07:52

    MichaelMure on master

    Fix invalid tab selection conso… Only set bugtitle if title is d… Replace switch to save lines of… and 1 more (compare)

  • Apr 10 07:50

    MichaelMure on master

    Deal with github bridge import … Fix errors: deadlock and empty … Remove maps containing channels… and 14 more (compare)

  • Apr 10 07:50

    MichaelMure on dev-gh-bridge

    (compare)

  • Apr 10 07:50
    MichaelMure commented #585
  • Apr 09 19:34
    sergeevabc commented #551
  • Apr 09 13:58

    rng-dynamics on dev-gh-bridge

    Revert "Bridges: move credentia… Github brdige: move credential … (compare)

  • Apr 09 13:34
    rng-dynamics commented #585
Michael Muré
@MichaelMure
the mock will give you that
happybeing
@happybeing:matrix.org
[m]
Thanks Michael. I'm thinking there the bridges may well be useful, in fact any part of git-bug/go-git is potentially useful though there will be alternatives (such as CLI or rewrite) so it is a "nice to have the option" only. As I say, I'm fine with what I have for the time being, I just thought it would be sensible to merge changes since my fork to keep the codebase from diverging too much.
I'm tethering too and it can take well over a minute to load first time. I agree caching can help, but any issue like this deters use and to be a serious contender initial load time is very important. It makes a bad first impression when you visit a website and it is just loading even for a few seconds, a lot of people give up at that point or think it will always be like that and not come back. So while its fine for the proof-of-concept, I think its a serious issue for adoption of a product.
I don't need to make a decision yet so just keeping these areas under review for the time being.
happybeing
@happybeing:matrix.org
[m]
I think we'll now focus on the UI for a while and just extend my Go API to support that based on the existing fork. See how far we can get with this.
Michael Muré
@MichaelMure
definitely agree with the first impression thing, it's just that aiming for perfection often prevent you from reaching anything
if you'd like I can merge the kind of repo we discussed, it would be just another implementation in the same package
happybeing
@happybeing:matrix.org
[m]
Initial load time is very important, so for me this isn't about perfection but viability (for widespread adoption).
happybeing
@happybeing:matrix.org
[m]

if you'd like I can merge the kind of repo we discussed, it would be just another implementation in the same package

Sure, if you'd like to do that in a way so I can pass the filesystem in that would be great. It needs to be used for .git/git-bug issues and go-git .git and worktree as a minimum, which is what I have now, when passed to either Open or Init. I also need to be able to access the gogit.Repository so I added an accessor:

// GetGitRepo provides external access to the gogit.Repository implementation
func (gr *GoGitRepo) GetGitRepo() *gogit.Repository {
    return gr.r
}
Michael Muré
@MichaelMure
what do you need that for?
Michael Muré
@MichaelMure
Hoooo
Go 1.16 is almost out and brings an official alternative to billy: https://tip.golang.org/pkg/io/fs/
I can see that being used in various packages
happybeing
@happybeing:matrix.org
[m]
Sounds good. I'm using gogit.Repository to access commits at the moment - having ensure it is created in the same billy-fs as the RepoCache.
I could also use it to access the git config.
Michael Muré
@MichaelMure
Well, that works, but why not using Repo instead of bypassing it and reaching to gogit?
happybeing
@happybeing:matrix.org
[m]
Probably ignorance. I take a look, thanks.
I think it wasn't clear to me how to do this quickly for the proof-of-concept (maybe the docs could be clearer or more examples - not sure - I am in get something to work fast mode mostly) but I quickly found an example from go-git so implemented something based on that.
happybeing
@happybeing:matrix.org
[m]

Yes, looking at the docs I don't see examples. You have function definitions with one line explanations (as is the way for most Go packages, but that's not enough IMO. For example:

func (*GoGitRepo) ListCommits

func (repo *GoGitRepo) ListCommits(ref string) ([]Hash, error)

ListCommits will return the list of tree hashes of a ref, in chronological order

This is an area which Go could improve a lot I think, not just your docs. I think generally they've set the bar low and people follow that lead.

Michael Muré
@MichaelMure
To be fair, those functions are very tailored for git-bug usage so it might not really suit you
Doc is a bit succint but that doesn't have much to do with go, it's just my style
I'd welcome improvements though
happybeing
@happybeing:matrix.org
[m]

That was my impression (git-bug specific), hence I looked elsewhere.

Succinct can be good so long as it's obvious where to go if it's not enough. Your generated docs are similar to but better than much of the Go module documentation, which is why I see it as a Go thing. Go package docs are mostly bare.

I can't write or improve documentation for stuff I don't understand! My suggestion is to have a line for each parameter and return, and ideally a short example for each function. Maybe also a link to a page that has an example covering a more realistic use case. It's a lot of work for the author, but saves much more overall for everyone. I don't expect this from a small project, just saying what I find a useful approach when trying to understand and use stuff.

Some systems are better at this than others. A nice thing about Rust is that you can insert your test code in comments before the function, and this can be included in the documentation as an example. Not the prettiest way, but helps reduce the work needed to provide examples. I've not done that myself yet because so far I've only made one learning project in Rust.

On the other hand finding certain things in the Rust docs can be tricky until you get the hang of them! The ecosystem obviously has the benefit of much more effort going into it, which given Google is behind Go and Mozilla is behind Rust I was very surprised to discover. It really looks like Google care little about Go.

By the way, I did try Goland briefly but found it dated (I couldn't change the size of UI elements for example) and went straight back to VSCode which seems superior. I hate the fact VSCode is from Microsoft, but it is the best free stuff around IME. Go is very well supported by using a plugin - there are plugins for almost every language and document format, and they tend to be very sophisticated (all free).

rng-dynamics
@rng-dynamics
@MichaelMure, sorry for the inconvenience, but could you send me the invitation to the git-bug organisation again? (The old invitation is expired.)
Michael Muré
@MichaelMure
@rng-dynamics well, the git-bug org is useless for now (there is only me), and you are a collaborator of the git-bug repo already
so everything looks fine
vmiklos
@vmiklos:vmiklos.hu
[m]
oh, this matrix <-> gitter gateway actually works, we can have nice things
Michael Muré
@MichaelMure
Gitter is now powered by matrix ;)
rng-dynamics
@rng-dynamics
Hi @MichaelMure, I am currently working on the Github bridge issue #315. At Github there exist Issues which have a title equal to the empty string. E.g., NixOS/nixpkgs#72730 . NixOS/nixpkgs is one of my test cases. When I try to import that, then I get the error "import error: issue creation: title is empty". AFAIK this error is not at the level of the bridge but emitted by a call to repo.NewBugRaw(). What do you think? The fastest and simplest solution for me would be to check the string for emptyness and then set the string to the issue number.
Michael Muré
@MichaelMure
ho wow, I had no idea that was possible!
this is indeed the data-model of git-bug that require a non-empty title. This is reasonable I think. Your idea is correct, the bridge should normalize the data to fit into git-bug. Using the issue number looks fine to me. Another way would be to use <no title> or something like that but then there is the possibility of to have more than one of those.
@rng-dynamics
rng-dynamics
@rng-dynamics
Sounds good. I will use the the issue number for now. Obviously, the actual string can be changed easily.
Michael Muré
@MichaelMure
indeed
vmiklos
@vmiklos:vmiklos.hu
[m]
hmm, if i do a bridge import form github (for mirror / backup purposes) and i want to publish that in the original repo, so other users don't have to mirror themselves, how do i do that? is this a matter of git push origin refs/bugs/*:refs/bugs/* and then same for identities?
vmiklos
@vmiklos:vmiklos.hu
[m]
yes, that seems to work (with git fetch refs/bugs/*:refs/bugs/* on the other side, then same for identities)
Michael Muré
@MichaelMure
That's correct, but you can just use git bug push to do that
vmiklos
@vmiklos:vmiklos.hu
[m]
Ah, thanks. I didn't notice it :)
vmiklos
@vmiklos:vmiklos.hu
[m]
hm, actually when i try git bug pull with remote.origin.url set to git@github.com:author/myproject, then i get Error: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain but if i edit .git/config to contain git://... then it's fine. is this a known problem?
vmiklos
@vmiklos:vmiklos.hu
[m]
and yes, normal git pull works
Michael Muré
@MichaelMure
@vmiklos:vmiklos.hu what version of git-bug are you using?
vmiklos
@vmiklos:vmiklos.hu
[m]
@MichaelMure this is master
Michael Muré
@MichaelMure
it's probably this issue then go-git/go-git#218
I've been considering to keep exec() the system git binary for some operation like push/pull, I guess I might need to do that
:(
vmiklos
@vmiklos:vmiklos.hu
[m]
yes, seems so. not a huge problem, i now added a git-bug remote which uses git:// as a workaround for now
thanks for the link, good to know the root cause :)
rafasc
@rafasc
Not sure if this is worth pointing out, but the tag pattern changed from x.y.z to vx.y.z on this latest tag.
Michael Muré
@MichaelMure
@rafasc yeah it was on purpose, apparently go package require the v
rafasc
@rafasc
ah, makes sense. Thanks for the clarification.