Would it be possible prioritize bugs/features (alphabetical: "prio:H/M/L" or numerical) and sort accordingly?

Saw this on Reddit:

is that you lose the ability to fork and merge bugs (at least, not automatically with git branch and git merge)

That's correct, but that's because there is no low level git command that can rebase branch without touching the index. It's really just a shortcoming of git because no one has a serious use case for that (yet). I wrote code in git-bug to do that manually. If that is fixed in git, the data model allow for automatic merge.

FYI, it is possible, but not "trivial". The raw Git commands to do this are in this file. Basically, you make a new index file and work tree and convince Git that things are OK and then you can operate as normal (though only files that Git needs to drop will be dropped; namely conflict files).

It is possible to do the same things using libgit2.

First, this is another issue that only shows up in the most recent commit, but is not present in the release. Do you want these issues? If not I'll stop reporting them and wait for the next release.

The issue now is if I open the termui and register a comment on any issue, this comment will not appear in the termui until I restart it. It doesn't even refresh if I open a new issue in the termui and comment on that. See another gif showing the problem

Todo:

git bug rm <id> [<remote>]: remove a bug locally or on a remote

Notes: this will require a way to pull only partially the bugs (for instance, only bug active in the last year).

hello Michael,

i just started to use git-hub and naively tried to use help ... as those
commands release an informative message:

git-bug --help
git-bug -h

this one doesn't and it really saddens me as i feel it should work the way the git command do

git-bug help

thanks for your work

regards
marc
(PS: also: a link to read which i'm almost agree with.. i'll clearly test the "mind the stream" part:https://medium.com/@jdxcode/12-factor-cli-apps-dd3c227a0e46)

Creating new issues using either new or termui will both create an issue at unix zero time (1970/01/01). This is a newly introduced bug as it happens with the current master branch (commit 0728c00, fetched and built with go get), but is not an issue in the latest release (v.0.2.0).

Now that the importer is working (:tada:), an exporter would be neat.

It will probably need #55 to be resolved though.

It would be neat to support comment edition or removal. A few notes:

• require two new Operations
• as the data model is immutable, it would not fully erase the previous comment version. While it would not be visible in the UI anymore, it would still be readable through the bug history.
• in bug.Snapshot, a proper Timeline needs to be implemented and would replace the current usage of Operations. This Timeline would hold the data that is expected to be displayed in a UI, instead of the raw stream of events

I have installed git-bug with go get github.com/MichaelMure/git-bug.
When I run git bug webui it starts web-server but returns 404 for index.html.
GraphQL API and Playground are working fine.

Precompiled binary from github releases isn't affected with this problem.

❯ git bug --version
git-bug version 0.2.0

❯ ~/Downloads/git-bug_linux_amd64 --version
git-bug version 0.2.0

I would prefer git-bug not to include a webserver by default.

In #5 @MichaelMure settled on JSON as a serialization format.

Feature request: add a CLI command to export the issue repository.

Something like: git bug export that just exports the whole issue repo as JSON would be great.

I am trying to use git bug on one of my repositories, and it doesn't seem to properly register new bugs. First of all, this might be normal-ish, but every time I run more or less any git-bug command it shows:

A lock file is present but the corresponding process is not, removing it.

Second, my new issues aren't registered properly. That is, if I create an issue it doesn't show up in the git bug ls command output, nor in the termui. However, if I push the bugs, they do show up in that list, and I can show their content if I run git bug show on the SHA.

It did manage to register one issue, my first one, and I can still interact with that bug by adding comments and labels, but no new bugs show up.

One thing that might be related is that all my bugs show up as having been added at the start of unix time (1970/01/01), not exactly sure what is happening. I installed git-bug by using the go get option, and here are some information that might be useful:

OS: Ubuntu 16.04.4
git: 2.7.4
go: 1.8.3

Git version is somewhat old, with might be the issue here. I can try to get a newer version and see if that helps. I ran an apt upgrade after adding the git PPA, but it somehow managed to mess up my system to the point of no return, so it is a bit hard to me to check. Sorry about that.

Right now, commands get killed by a SIGINT and the lock file is not properly removed.

As the cache is smart enough to see that the previous process is gone and clean the file, it's not that much of a problem, but it would be cleaner.

In a similar fashion as git-bug, Github expose in its graphql API both compiled data of an issue and a timeline of events.

{
  repository(owner: "MichaelMure", name: "git-bug") {
    issues(first: 10) {
      nodes {
        title
        createdAt
        bodyText
        labels(first: 10) {
          nodes {
            name
          }
        }
        timeline(first: 10) {
          nodes {
            __typename
            ... on IssueComment {
              author {
                login
                avatarUrl
              }
              authorAssociation
              bodyText
              createdAt
            }
            ... on LabeledEvent {
              createdAt
              actor {
                login
              }
              label {
                color
                name
              }
            }
            ... on UnlabeledEvent {
              createdAt
              actor {
                login
              }
              label {
                color
                name
              }
            }
          }
        }
      }
    }
  }
}

We can use this timeline to import issue into git-bug. However, there is some mismatch that need to be resolved. Notably, in git-bug, a person is:

type Person struct {
	Name  string
	Email string
}

Where for Github, an actor is:

avatarUrl (URI!)
A URL pointing to the actor's public avatar.

login (String!)
The username of the actor.

resourcePath (URI!)
The HTTP path for this actor.

url (URI!)
The HTTP URL for this actor.

I was thinking about how I usually work with a bug tracker and I realized that I often keep several bugs open in a browser tab to keep in my mind or to have a quick glance without having to loop up for them.

This behavior is difficult to replicate with the terminal UI. Having a query for the bug you are assigned to come close but it's not the same thing.

My idea is to have the ability to favorite arbitrary bug and have a query to select the marked bugs. These metadata would not be persisted in the bug state but only locally.

Does that ring a bell for someone else ?

hello,

if
git-bug add

could act as

git-bug add --file -

it would be great

For now, comments are rendered in the CLI and termUI as pure text. It would be neat to have markdown instead.

While it's easy to find a renderer that output HTML, finding one that render as text or even better text formatted with terminal escape sequence is more tricky.

Need some investigation.

$ git --version
git version 2.11.0

$ git bug show 0178f12
Error: fatal: unknown refname: format lstrip=-1
Usage:
  git-bug show <id> [flags]

Flags:
  -h, --help   help for show

fatal: unknown refname: format lstrip=-1

support for git for-each-ref --format '%(refname:lstrip=-1)' was
added 2.13.2

It would be neat to have a logo for git-bug.

Someone to assist here ?

git-bug supports fetching from multiple repositories but once bugs are fetched they all go inside the same bag: .git/refs/bugs/<oid>. This makes it impossible to keep bugs from different sources separate.

Use cases can be:

• public and private bug trackers.
• pulling and pushing bugs from multiple forks while keeping them separate.

When it comes to namespacing references, the usual solution in git is to just make a path based namespace scheme. So using something like .git/refs/bugs/default/<oid> would be the easiest solution to allow the use of other namespaces, e.g. .git/refs/bugs/private/<oid>

Another possible candidate is gitnamespaces as in https://git-scm.com/docs/gitnamespaces.

And of course, something would need to be done about the global state stored on .git/git-bug.

Thoughts?

I dig how the bash completion code gen works. If anyone knows how to do the same on windows we could codegen what it needs to work also.

Then the question is what windows shell to target ? Good old CMD or Piwershell ? I don't know what the advice would be for Windows 10 these days

I guess it's also important to get feedback from other Devs ( thumbs up for example ) so we know if this is worth the effort too.

It would be nice – and make it easier to get an overview of what needs to be done – to be able to hide closed issues when doing a git bug ls.

Currently, each Operation store the author independently. While it's easier and works well for now, there is some shortcoming:

• no way to update an identity (update an email, update an avatar ...)
• no easy way to recognize that two author are the same
• data is stored multiple time (no that much of an issue with the git compression)
• crypto signature & authorization scheme is hard to implement

So I've been thinking it could be changed for the following (rough idea):

• identity (including a public key would be neat) is stored as a JSON in a git blob
• this blob hash give the id for this identity
• each time an identity is updated, a new blob is created with the new values and these blob are linked together in a chain of commit, the head being the last state.
• in each operations, actor(s) are simply identified with the id.

Now, I'm not sure yet how these identities should be stored and distributed. a git ref for each identity ? Each required identity linked in the OperationPack git tree ? A master ref aggregating all known identities ?

Hopefully this would be the last of the backward-incompatible change in the data model

To be able to auto-complete bug id from a prefix, a hidden command to query the repo for matching id is necessary.

git bug ls-id [<prefix>]

If no prefix is given, output all existing id.

It would be nice to be able to assign each label a color, and use that color every time the label is printed.

Hello,

Thanks for your work on this! I looked through the source code and I don't think I'm missing anything, but it would be great to be able to close a bug via termui when you are in a particular bug's view.

If that is in fact a feature that's missing, I'd be happy to work on a PR to add it. My apologies if it already exists and I just haven't figured it out yet! 😄

Thanks!

Low priority, but eventually git-bug should be translated in various language.

At first glance, it doesn't to be an established way to do the i18n in go. If you have experience with that, please share it here.

Dear everybody,

We are just starting to use git-bug. It's really awesome. I'd like to request a new feature:

support hooks for comment and title messages

git has a lot of hooks. Among them, there is the commit-msg hook that one can use to audit/verify COMMIT_EDITMSG.

For example, commitlint provides a very convenient and standardized commit message rule set and helps improve the commit message quality for many projects such as Angular.

I'd like to be able to have the option to enforce commit message rules as I could with commit-msg hooks in vanilla git.

Thanks a lot for your work and attention.

Zhongming

This is a really cool project.

The next step for me would be to support branch reviews with discussions to replace merge requests.
Do you have any plans for this?

The rough features needed would be:

• multi-user discussions on changesets within files
• marking a change as "needs improvements"
• Resolving discussions and improvement requests
• Marking a commit as approved

ps: I'm happy to help out with this if you see this within the project scope.

In Firefox when I open a bug in a new tab, it results in a 404 error (404 page not found). I don't have this error when opening a bug in the current tab and the urls seems identical.

For now, the default git remote is hard-coded as "origin". While this will work most of the time, having this being configurable would be nice.

Git handle this configuration separately for each branch so we can't reuse that system.

I guess the best way to do that would be using the git config system and having an entry like gitbug.defaultremote=origin.

In git-bug, we will also need a config package that read and expose this.

Todo:

git bug diff [<id>] [<remote>]: show what bugs have been added/changed regarding the default or explicit remote. No select mechanism here, the is a filter.

As we can store arbitrary data in the git storage and reference it in a commit, we can support media in bug's comment.

In particular, we can have:

• images (jpg, png, gif ..)
• video (as supported by major browser)
• arbitrary files

Markdown support images but not video (though gitlab reuse the same syntax: https://gitlab.com/help/user/markdown#videos), nor arbitrary files.

On top of that, as files would not be in the normal repository, we need a way to reference the corresponding blob.

A way to do that might be:

Inline-style:
![alt text](e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 "logo.png")

Reference-style:
![alt text1][logo]

[logo]: e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 "logo.png"

Additionally, git-bug could enforce the reference style to make it more readable for terminal users.

Here's a particular example: aurutils/aurutils#363.
From my brief conversation with @MichaelMure on Gitter, this seems to be caused by not handling deleted edits properly.

Kind of like how it works in GitHub where you can references an issue # (or maybe short hash, but a number would be easier to remember) in a commit message and that reference displays a link/reference in the issue timeline (and closes the issue if you put something like Closes #1?).

Todo:

git bug reset <id> [<remote>]: clear the changes of a bug to match the bug of a remote

Question: can git-bug bugs "branch" and "merge" (similar/same as regular git files/content)?

If not, does it make sense to add such a feature in the future?

What do you think of renaming the project to git-issue?

I find the name issue is more descriptive of what we do on software project based on git and this is the current convention used by gitllab and github.

I know that bug is shorter that issue bug we could use alias.

To be consistent with git core, I suggest the following commands and behaviours:

• git bug lists bugs (replaces git bug ls)(similar behaviour to remote and branch)
• git bug --help shows available commands (replaces git bug commands)
• git bug add creates a new report (replaces git bug new as commands should be verbs)

When installing the project with go get on ubuntu 16.04, I have the following error:

ᐅ go get -u github.com/MichaelMure/git-bug
package context: unrecognized import path "context" (import path does not begin with hostname)
package github.com/MichaelMure/git-bug/vendor/github.com/shurcooL/go/ctxhttp: no buildable Go source files in /home/augustin/.go/src/github.com/MichaelMure/git-bug/vendor/github.com/shurcooL/go/ctxhttp

Indee my go version is 1.6.2, and apparently context appeared in go 1.7.

I didn't open a PR because I don't know what's the best way for this : can it be constrained in the Gopkg.toml? Or can we only document this?

thanks!

To make browsing issues easier it would be really great if we could have shell completion on par with git completion in zsh (not sure how well it works in bash). Ideally typing git bug show <TAB> would show a list of bugs similar to how git checkout <TAB> shows a list of branches and commits (see picture).

First off, this is super cool, thanks for sharing it!

I'll try and track what might be causing this down if I have some time, but for now I thought I'd submit it ahead of a PR.

Info on my setup:

• MacOS
• iTerm
• Vim as my default editor

The git bug termui seems to have an issue when you go to create a new bug but then leave it empty as if you were cancelling it. Here is my workflow that should reproduce it:

• git bug termui
• n to create a new bug
• when the new bug window opens for you to edit it (I use Vim), do a :q to exit without typing anything into the bug entry

After that I get the crash. Below is the output

[signal SIGSEGV: segmentation violation code=0x1 addr=0x60 pc=0x1224feb]

goroutine 1 [running]:
github.com/MichaelMure/git-bug/termui.(*showBug).renderMain(0xc42026e000, 0xc42037e000, 0xc420386000, 0x0, 0x1)
        /Users/esell/go/src/github.com/MichaelMure/git-bug/termui/show_bug.go:207 +0x11b
github.com/MichaelMure/git-bug/termui.(*showBug).layout(0xc42026e000, 0xc42037e000, 0x3b, 0xc4203375f8)
        /Users/esell/go/src/github.com/MichaelMure/git-bug/termui/show_bug.go:61 +0x1e8
github.com/MichaelMure/git-bug/termui.layout(0xc42037e000, 0x0, 0x0)
        /Users/esell/go/src/github.com/MichaelMure/git-bug/termui/termui.go:116 +0x4b
github.com/MichaelMure/git-bug/vendor/github.com/jroimartin/gocui.ManagerFunc.Layout(0x152d0f0, 0xc42037e000, 0x0, 0xc420337660)
        /Users/esell/go/src/github.com/MichaelMure/git-bug/vendor/github.com/jroimartin/gocui/gui.go:329 +0x30
github.com/MichaelMure/git-bug/vendor/github.com/jroimartin/gocui.(*Gui).flush(0xc42037e000, 0x2, 0xc42037e000)
        /Users/esell/go/src/github.com/MichaelMure/git-bug/vendor/github.com/jroimartin/gocui/gui.go:435 +0xd6
github.com/MichaelMure/git-bug/vendor/github.com/jroimartin/gocui.(*Gui).MainLoop(0xc42037e000, 0x0, 0x0)
        /Users/esell/go/src/github.com/MichaelMure/git-bug/vendor/github.com/jroimartin/gocui/gui.go:367 +0xb3
github.com/MichaelMure/git-bug/termui.initGui(0xc4203378d0)
        /Users/esell/go/src/github.com/MichaelMure/git-bug/termui/termui.go:101 +0xcc
github.com/MichaelMure/git-bug/termui.newBugWithEditor(0x156dfa0, 0xc420258060, 0xc420337b10, 0xc420337b74)
        /Users/esell/go/src/github.com/MichaelMure/git-bug/termui/termui.go:189 +0x1e7
github.com/MichaelMure/git-bug/termui.(*bugTable).newBug(0xc42025c140, 0xc42026e120, 0xc4202d60f0, 0xc42026c180, 0xc42026c120)
        /Users/esell/go/src/github.com/MichaelMure/git-bug/termui/bug_table.go:394 +0x37
github.com/MichaelMure/git-bug/termui.(*bugTable).(github.com/MichaelMure/git-bug/termui.newBug)-fm(0xc42026e120, 0xc4202d60f0, 0xc, 0xc420337b01)
        /Users/esell/go/src/github.com/MichaelMure/git-bug/termui/bug_table.go:173 +0x3e
github.com/MichaelMure/git-bug/vendor/github.com/jroimartin/gocui.(*Gui).execKeybindings(0xc42026e120, 0xc4202d60f0, 0xc420337a78, 0x121bce9, 0x0, 0x0)
        /Users/esell/go/src/github.com/MichaelMure/git-bug/vendor/github.com/jroimartin/gocui/gui.go:629 +0xce
github.com/MichaelMure/git-bug/vendor/github.com/jroimartin/gocui.(*Gui).onKey(0xc42026e120, 0xc420337a78, 0xc4201e1020, 0xc420268050)
        /Users/esell/go/src/github.com/MichaelMure/git-bug/vendor/github.com/jroimartin/gocui/gui.go:593 +0x1b3
github.com/MichaelMure/git-bug/vendor/github.com/jroimartin/gocui.(*Gui).handleEvent(0xc42026e120, 0xc420337a78, 0xc420337a70, 0x0)
        /Users/esell/go/src/github.com/MichaelMure/git-bug/vendor/github.com/jroimartin/gocui/gui.go:413 +0x40
github.com/MichaelMure/git-bug/vendor/github.com/jroimartin/gocui.(*Gui).MainLoop(0xc42026e120, 0x0, 0x0)
        /Users/esell/go/src/github.com/MichaelMure/git-bug/vendor/github.com/jroimartin/gocui/gui.go:373 +0x2cf
github.com/MichaelMure/git-bug/termui.initGui(0x0)
        /Users/esell/go/src/github.com/MichaelMure/git-bug/termui/termui.go:101 +0xcc
github.com/MichaelMure/git-bug/termui.Run(0x156f8e0, 0xc42000c0c0, 0x0, 0x0)
        /Users/esell/go/src/github.com/MichaelMure/git-bug/termui/termui.go:59 +0x221
github.com/MichaelMure/git-bug/commands.runTermUI(0x17b8ca0, 0x17df968, 0x0, 0x0, 0x0, 0x0)
        /Users/esell/go/src/github.com/MichaelMure/git-bug/commands/termui.go:9 +0x39
github.com/MichaelMure/git-bug/vendor/github.com/spf13/cobra.(*Command).execute(0x17b8ca0, 0x17df968, 0x0, 0x0, 0x17b8ca0, 0x17df968)
        /Users/esell/go/src/github.com/MichaelMure/git-bug/vendor/github.com/spf13/cobra/command.go:762 +0x468
github.com/MichaelMure/git-bug/vendor/github.com/spf13/cobra.(*Command).ExecuteC(0x17b87e0, 0x1403b14, 0xc420234400, 0x17df828)
        /Users/esell/go/src/github.com/MichaelMure/git-bug/vendor/github.com/spf13/cobra/command.go:852 +0x30a
github.com/MichaelMure/git-bug/vendor/github.com/spf13/cobra.(*Command).Execute(0x17b87e0, 0xc42009e058, 0x0)
        /Users/esell/go/src/github.com/MichaelMure/git-bug/vendor/github.com/spf13/cobra/command.go:800 +0x2b
github.com/MichaelMure/git-bug/commands.Execute()
        /Users/esell/go/src/github.com/MichaelMure/git-bug/commands/root.go:50 +0x2d
main.main()
        /Users/esell/go/src/github.com/MichaelMure/git-bug/git-bug.go:11 +0x20```

Is there any ongoing work to push into github/gitlab/gogs/etc support for handling issues created git-bug ?

It would be awesome.

At least the mime type should be stored (it's detected when uploaded already) so it can be set properly when downloading without having to load everything in memory to detect it. The name of the file might not be a bad idea either.

This metadata can be extended later for other uses.

These metadata should be stored in the AddCommentOp and the CreateOp so a file can be referenced in different message with different metadata. Bug's commits should only reference the blob's hash to carry files during push/pull.

When designing git-bug it would be very useful to have an overview of the various bug-trackers that are out there. Here is a sample of questions that I have:

Actor

• what properties (name, email, login, id, avatar ...) does the bug-tracker know about an actor ?
• what is mandatory, what is optional ?

Bug's state

• how do they model a state ? Is it an fixed set of state, or is it extensible? configurable ?
• how do they model the transition between these states ?

missing features in git-bug

• For instance, Github support reactions to messages with a set of emojis. What other bug-tracker support that ?
• What other important features other bug-trackers have ? Is there a common ground ? Are they incompatible ?

With the attention git-bug got lately, hopefully we can collaborate and fill the blanks together in a shared spreadsheet.

@adamslc said:

What are your plans for a git bug config command? To start off the conversation, here is an incomplete list of things that might possibly need to be configured. Note that I'm not arguing that everything on this list should actually be implemented.

* Default remote
* Set of possible labels
* Possibly move `git bug bridge configure` under here?
* Default new bug and comment templates
* Keybindings in `termui`
* Author data specific to git bug. I'm not sure if this exists?

Also, I think that having connivance flags to update the config from other commands makes sense. In #62 I suggested using -d and --set-default in git bug push to get and set the default remote. I'm now convinced that those aren't the right flags to use (looks to much like delete), but I still think that this is important functionality. Perhaps mirroring git push and using -u and --set-upstream would makes sense.

To have fields being self-documented in the API, we need to update gqlgen to the latest version (> 0.4.0) and document fields using https://facebook.github.io/graphql/draft/#sec-Descriptions.

This project is really great stuff.

I noticed the OT based approach for the Data Model for a BUG. Wondering if you think this is better thanthe CRDT approach ?

But anyway i was thinking about how lots of users have to fork and then manage setting up the brnahc and then doing a PR. It can be tricky for new golang users. SO i want to suggest that this be incorporated later. I saw a repo in golang just the other day that did this.

anyway, hope to hear your thoughts. The code base looks really clean and easy to follow and i want to congratulate you on this excellent work.

In terms of a github server, do you envisage users using gitea or other ?

Hello,

This project seems super interesting, and I've managed to quickly try it. I wanted to try and write some code for it, but I am unfamiliar with go.

The "make" command complained about missing packages, so I ran:

$ go get github.com/spf13/cobra/doc
$ go get github.com/MichaelMure/git-bug/commands

Now, make fails with another error:

$ make
go generate
# command-line-arguments
doc/gen_markdown.go:20:28: cannot use commands.RootCmd (type *"github.com/MichaelMure/git-bug/vendor/github.com/spf13/cobra".Command) as type *"github.com/spf13/cobra".Command in argument to doc.GenMarkdownTree
git-bug.go:1: running "go": exit status 2
make: *** [Makefile:4: build] Error 1

I feel like README.md should have specific instructions for developers. Experienced Golang devs will not learn much, but it would be really helpful for people like me.

Bug's data are stored using git Commit, Tree and Blob. Inside a Blob is serialized an OperationPack, that is an array of edit operation on the bug's state.

This OperationPack is currently serialized using golang's gob, which is neat because it just works. However, it might not be the best option for interoperability with other tools in the future.

How should that be serialized ? Json ? In any case, git will compress the data using zlib so a text format might not be that terrible.

Feel free to argue a case here.