4 ms·

@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.

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.