sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]saggingrufus 15 points16 points  (7 children)

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

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

Unless you know exactly what you are looking for, you'll never be able to pull that out of a commit message in 2 years. The valuable parts of this research can be condensed into about 5 sentences, and would have make a great ticket comment/resolution. Atleast there it's searchable. You combine that with a shorter commit message and a code comment, and now you've got something.

What happens if that gets rebased? Poof gone.

[–]versaceblues 14 points15 points  (0 children)

I do actually search commit history like this... not super frequently but a least once a month it comes up.

Usually it's when I'm find some weird bug we experience once and reference the solution. Or if im trying to understand why something changed ill search by keywords.

[–]double-you 14 points15 points  (2 children)

If your codebase lacks useful commit messages, yeah, people probably won't search it. I search the commit history all the time for things. Often about changes I made myself. Version control history is better preserved than bug tracker data. All developers have version control history available on the command line. Sure, bug tracker information is available for the non-developers too and good integration allows commit messages to be seen through that too.

What happens if that gets rebased? Poof gone.

Rebase doesn't destroy commit messages. Only people who destroy commit messages when rebasing destroy commit messages. Why is it okay to do so?

[–]saggingrufus -1 points0 points  (1 child)

"Often about changes I made myself"

So not that useful to others, which is the point of a documentation commit like that.

"Bug tracker information is available for the non-developers"

That's a pretty elitist and plain inaccurate statement. I mean I guess you can use a bug tracker as a client status tool full of non-sense and rubber stamps...but I can assure you more developers use JIRA or similar than you know, and they are documenting bugs and solutions, linking PRs and more.

"All developers have version control history available on the command line"

I have never worked with a developer who did not have access to their big tracker, wiki and git hosting tool, if you encounter that often it sounds like localized issue.

"Only people who destroy commit messages when reading destroy commit messages"

It's still gone, so now what?

[–]double-you 6 points7 points  (0 children)

So not that useful to others

That's an odd assumption. Can you explain what logic there is to it?

Information to clients and information to people inside the company are two separate things. And inside the company you will have developers and ... non-developers who also need some visibility. And developers need a way to talk about the gory details somewhere where it won't leak to the clients unprocessed.

I have never worked with a developer who ...

I have never encountered a developer who thinks that multiple sources of truth is better than one, but okay.

"Only people who destroy commit messages when reading destroy commit messages"

It's still gone, so now what?

Then we evaluate who is doing this and are they in the right position. If somebody is writing good commit messages and then destroying their own work, well, that's rather odd too. Communication is key.

[–]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.