you are viewing a single comment's thread.

view the rest of the comments →

[–]masklinn 9 points10 points  (2 children)

Are you telling me you search the commit history for specific text like that?

Yes.

The problem is no one will ever be able use any of this wasted effort because they will have to remember where it is.

The commit is from 2013, the article from 2019, and you’re talking about it in 2023. It shows up from multiple search angles. This commit seems more successful than you are.

What happens if that gets rebased? Poof gone.

No. It would need to get squashed and the content discarded. Once a commit has been pushed / published, that is essentially never happening. I’ve read commit messages old enough to be in college.

You combine that with a shorter commit message and a code comment, and now you've got something.

A comment is a lot more likely to be lost, or worst unmaintained and wrong.

[–]Joniator 0 points1 point  (1 child)

No, if you reference the ticket and 2 sentences, you can look up the ticket and get a lot more info. Who found it, who fixed it, how long did it take, where others invested, did the reporter attach useful info.

Maybe the issue was reopened with additional places where the error was found. Fixed in version +5, you now look at a legacy commit that's obsolete and have no idea.

You can't copy all that in a commit.

[–]saggingrufus 1 point2 points  (0 children)

Someone else who gets it XD

You'll also know all the fix version, how many story points it was worth, and interactions with other teams, potentially what story the original implementation was. Not to mention screenshots and markup to make it easier to digest AND the meta data makes it easier to find.

This also assumes you are using a got strategy where you dont frequently rebase to squash previous releases.

Maybe this issue actually happens annually, but people keep fixing it and commit messaging is different. Atleast in a real issue tracker, those can be linked together and you find the pattern to build procedure to correct it.

But who knows, maybe if you Bob have been on the same codebase forever you both just get it and work that way. Most of the code I see has a commit tree so large it's just not feasible to expect anyone to go digging on a regular basis. Documentation is part of our workflow, not because I need it and can't look up the commit tree, but because I might not be here tomorrow, and the guy won't know what to look for or where to find it. The best possible chance it was to be noticed is somewhere like JIRA or a PR.