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