Hacker News Reader

Comment by adamlett | Hacker News Reader

I say yes. I like to keep information about the code as close to the code as possible. Issue trackers come and go, and even if you keep the same issue tracker around, how are you going to relate the change in the code to the particular issue down the road?

FWIW, I also prefer READMEs to Wikis.

View on HN

> Issue trackers come and go

Unless you use Fossil :-P. Or for git/hg/svn/cvs/Folder - Copy(43), one of those ticket trackers that work with files inside the repository itself.

> Issue trackers come and go

What do you mean? Just put an issue ID in the code and/or commit.

Let’s hope the SaaS issue tracker you’re currently using never goes out of business or changes the product in a way that makes it worse for you. Or, if you host your own, that it keeps you satisfied in perpetuity.

Referring to the issue ID in the commit message is a fine practice in addition to writing good, comprehensive commit messages. Commit messages that consists only of an issue ID are – in my experience – utterly frustrating to deal with. They tell you nothing more than this change is somehow related to this or that bug or feature, but not how or why.

> Let’s hope the SaaS issue tracker

So the solution to a unreliable issue tracking solution is dumping that responsibility on your VCS? Why not fix the concerns you have with your issue tracker?

> writing good, comprehensive commit messages. Commit messages that consists only of an issue ID

Who said anything about only including a tracker id? The issue here is the extra verbosity in the commit message. What will the tracker tickets contain that isn't in your "comprehensive" commit message?

* So the solution to a unreliable issue tracking solution is dumping that responsibility on your VCS? Why not fix the concerns you have with your issue tracker?*

… Or, and hear me out, how about not worrying about that, and just use your VCS to accomplish something it’s imminently well suited for?

Also, how do you propose I solve the issue of the issue tracking service maybe going out of business or that of a more compelling product coming along?

To me, the primary purpose of an issue tracker is to collaborate on and track work in progress, and that’s what I use them for. I don’t find that they are particularly valuable as historical records of the source code.

But then you switch out your issue tracker service from something like Jira to something else, and suddenly that ID or URL means squat. A git repository can easily be pushed to any git based service be it GitHub, GitLab, Gitea, or something else, and the commit log and commit hashes stays the same.

Porting Jira issues to a different system would probably not preserve those IDs that you entered into your commit message. By all means, refer to your issue tracker in commit messages, but be aware that those references may not be valid in a few years.

Just put the old ID in the new ticket, then search. Or put commit hashes into the ticket and search by that.

> A git repository .. and the commit log and commit hashes stays the same

If issue trackers are so transient and flaky, and VCSs are so solid, then back up your old issue tracker and put it in git. What if your issue tracker stays, but you VCS changes?

As close to the code as possible means a code comment, not a commit message.

Reply on news.ycombinator.com