4 ms·

> Git is distributed but all the things around it that we really need aren't Can anyone recommend an issue tracker that is distributed with the repo?

by jolmg 7y ago

Griffinsauce 7y ago
@TODO comments strewn around in your repo.
- jolmg 7y ago
  I was thinking of something that wouldn't be affected by the git history. There's no point in having branches for issue comments. Something like: $ git issue add "foo doesn't work" Created issue ece5591: foo doesn't work $ git issue comment ece5591 "the problem might be with bar" Created comment 0191fa1 on issue #10. $ git issue comment --reply 0191fa1 "or with baz" Created comment f98e783 on issue #10. $ git issue show ece5591 foo doesn't work -- ece5591 Your Name <your@email> the problem might be with bar -- 0191fa1 Your Name <your@email> or with baz -- f98e783 Your Name <your@email> $ git issue push Pushed issues ece5591. $ git issue pull Pulled issues 3ebdc7e, 24cdb90. EDIT: I just gave myself a clue: https://github.com/dspinellis/git-issue https://github.com/dspinellis/git-issue
  - WorldMaker 7y ago
    The nice idea to having issues in your history/branches is that it easily inverts the "flow" of branch state information: most issue trackers do a lot of work to figure which changes affect which issues, and which branches those changes are in. This often requires a lot of explicit manual work like making commit notes always include issue numbers for instance and "magic" commands like "Resolves #10" to auto-close issues. If the issues are just another source artifact alongside the code in the same git history a lot of that information flows the other direction. Instead of a magic command in a commit note to close an issue, an issue closing shows up in a diff in the commit. Figuring out which issues are still open in a given branch (what isn't in our release branch yet?) is a simple command in a branch. Figuring out which issues changed between branches (what's finished in this feature branch that hasn't been merged to release yet?) is a typical diff operation. In terms of documenting the state and progress of an individual branch in a complex project there can be a lot of magic in having issues tracked directly inside code branches. It's a fascinating ideal for code documentation to have issue comments, changes, and workflows side-by-side the code that changed with it. That said, issue trackers are sadly not ideal code artifacts for a lot of reasons, including that it is easy to forget that issues aren't just for coders, but also stakeholders/product owners/PMs/etc.
michaelmure 7y ago
I'm building one: https://github.com/MichaelMure/git-bug https://github.com/MichaelMure/git-bug
Madeindjs 7y ago
A commited todo.txt [1] file with project. [1]: todotxt.org
Izkata 7y ago
There were a whole bunch of these being actively developed around 2009-2012, but all of them slowly died out because each one had at least one of several issues that made them difficult or annoying to use, usually either requiring forgettable steps to actually distribute, or polluting the commits/branches with their own tracking. My personal solution is similar to sibling comments, but more structured - using vimwiki in a subdirectory inside the repo, and committing updates alongside the relevant code changes.

> Git is distributed but all the things around it that we really need aren't Can anyone recommend an issue tracker that is distributed with the repo?

by jolmg 7y ago

> Git is distributed but all the things around it that we really need aren't Can anyone recommend an issue tracker that is distributed with the repo?

Griffinsauce 7y ago

@TODO comments strewn around in your repo.

jolmg 7y ago
I was thinking of something that wouldn't be affected by the git history. There's no point in having branches for issue comments. Something like: $ git issue add "foo doesn't work" Created issue ece5591: foo doesn't work $ git issue comment ece5591 "the problem might be with bar" Created comment 0191fa1 on issue #10. $ git issue comment --reply 0191fa1 "or with baz" Created comment f98e783 on issue #10. $ git issue show ece5591 foo doesn't work -- ece5591 Your Name <your@email> the problem might be with bar -- 0191fa1 Your Name <your@email> or with baz -- f98e783 Your Name <your@email> $ git issue push Pushed issues ece5591. $ git issue pull Pulled issues 3ebdc7e, 24cdb90. EDIT: I just gave myself a clue: https://github.com/dspinellis/git-issue https://github.com/dspinellis/git-issue
- WorldMaker 7y ago
  The nice idea to having issues in your history/branches is that it easily inverts the "flow" of branch state information: most issue trackers do a lot of work to figure which changes affect which issues, and which branches those changes are in. This often requires a lot of explicit manual work like making commit notes always include issue numbers for instance and "magic" commands like "Resolves #10" to auto-close issues. If the issues are just another source artifact alongside the code in the same git history a lot of that information flows the other direction. Instead of a magic command in a commit note to close an issue, an issue closing shows up in a diff in the commit. Figuring out which issues are still open in a given branch (what isn't in our release branch yet?) is a simple command in a branch. Figuring out which issues changed between branches (what's finished in this feature branch that hasn't been merged to release yet?) is a typical diff operation. In terms of documenting the state and progress of an individual branch in a complex project there can be a lot of magic in having issues tracked directly inside code branches. It's a fascinating ideal for code documentation to have issue comments, changes, and workflows side-by-side the code that changed with it. That said, issue trackers are sadly not ideal code artifacts for a lot of reasons, including that it is easy to forget that issues aren't just for coders, but also stakeholders/product owners/PMs/etc.

michaelmure 7y ago

I'm building one: https://github.com/MichaelMure/git-bug https://github.com/MichaelMure/git-bug

Madeindjs 7y ago

A commited todo.txt [1] file with project. [1]: todotxt.org

Izkata 7y ago

There were a whole bunch of these being actively developed around 2009-2012, but all of them slowly died out because each one had at least one of several issues that made them difficult or annoying to use, usually either requiring forgettable steps to actually distribute, or polluting the commits/branches with their own tracking. My personal solution is similar to sibling comments, but more structured - using vimwiki in a subdirectory inside the repo, and committing updates alongside the relevant code changes.