Live data from Hacker News

Git log is not a changelog

agateau.com

81–90 of 92 posts

Re: Git log is not a changelog

#81
post #80

Earlier quoted context omitted.

Some of those comments were in response to people calling me a liar with upvotes on their comments and downvotes on mine. It's incredibly irritating and frustrating when it appears those accusing me of lying not suffer any consequences. For example (one that you linked to) a person said I was wrong and his comment wasn't flagged yet when I asked him to stop replying to my comments (many of my comments in the thread w…

It's certainly irritating and frustrating, but it doesn't make it ok to break the rules. If you see a post that ought to have been moderated but hasn't been, the likeliest explanation is that we didn't see it. (There are far too many posts here for us to read them all.) You can help by flagging it or emailing us at hn@ycombinator.com. https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor...

(Mostly a rhetorical question) I'll probably never be able to do that if it's based on karma but my question is, if I stop saying things that get my comments flagged but proceed to get into negative ranking (ex: -50 or maybe -100 if I get on an unlucky roll) will I be banned by the system automatically? I assumed so which was the other reason that annoyed me

Re: Git log is not a changelog

#82

Earlier quoted context omitted.

Let's say you have some code written 2 years ago. 2 months ago someone made a bug fix in the code replacing a few of the lines. How would you know from test, specs or examples which specific lines were modified and by whom? I don't get it.

Why would I want to do that? Usually if there's a problem I'll either write a new test or see if someone modified a test I thought was covering the case Usually people 'own' a file or part of the system so that wouldn't really be happening anyway

As I look at the top ten committers to our key service, two of us are still here, the other eight (including the lead from day one) switched teams or left the company over the last five years. Unfortunately I don’t think 27% turnover per year is unusually high in tech, so ownership isn’t a good replacement for written records.

Re: Git log is not a changelog

#83
post #80

Earlier quoted context omitted.

It's certainly irritating and frustrating, but it doesn't make it ok to break the rules. If you see a post that ought to have been moderated but hasn't been, the likeliest explanation is that we didn't see it. (There are far too many posts here for us to read them all.) You can help by flagging it or emailing us at hn@ycombinator.com. https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor...

(Mostly a rhetorical question) I'll probably never be able to do that if it's based on karma but my question is, if I stop saying things that get my comments flagged but proceed to get into negative ranking (ex: -50 or maybe -100 if I get on an unlucky roll) will I be banned by the system automatically? I assumed so which was the other reason that annoyed me

If karma goes below a certain threshold (I think it's -12) then the account's comments get autokilled, but only for as long as the karma remains below that threshold.

Re: Git log is not a changelog

#84

Earlier quoted context omitted.

> The purpose of a git commit message is to answer the question “why does this commit exist?” Why? Every time I have asked this people say because you'll search the logs (which I have never done in my life) or because "it's good practice"

If you have never needed to find out why a particular piece of code is the way it is, then you have been very lucky to work in very clean code bases. In my own experience, this has been an infrequent but inevitable part of work - maybe once a month or so, I have had to understand whether a particular piece of code, that seems wrong, had a good reason for existing or not. Sometimes it turned out to be a mistake in the…

ArrayBoundCheck didn't say they never had to find out why a particular piece of code is the way it is, just that they didn't have to search through log messages.

For isntance, when you use "git blame" and similar tools, the log messages are not involved. You might end up reading the log message of the commit that was responsible for a change, but you didn't search log messages to get there.

In a project with poor commit messages, they will be of little use; reading them won't produce much value, let a lone searching.

Anyway, that seems like the best possible interpretation of the user's comment, anyway.

Re: Git log is not a changelog

#85

Earlier quoted context omitted.

I think you just haven't discovered you can? I don't know of anyone arbitrarily looking through logs, but it's incredibly useful with git blame when you get to a section of code and don't understand it or typically it's done in an odd or unintuitive way. The blame shows who wrote it, information as to what they were working on via the actual commit message, and branch information. If the person still works with you,…

I'm starting to understand why. It appears my workflow has the information other people would want from a git log elsewhere (test, specs, examples, etc)

That's right; for log messages to be useful, they have to be very disciplined. They have to stick to a certain format and then if the information you're looking for is of the kind which is provided by that schema, then they are useful.

As an example, say log messages are strictly required to contain a bug database ticket number (even if they are not fixes: bug database tracks tasks too) then that is useful; you can quickly search the git log for a bug number to find all of its commits.

Re: Git log is not a changelog

#86
post #38

Earlier quoted context omitted.

Why are you searching a year or more back? Is this using git blame?

To explain why a certain block of code exists. When the code came into existence is rarely that important. You just want to know why. Why does the code fence against a particular circumstance you didn't think should be possible? Why does it call out to something you think is unrelated? Those questions can be answered by a proper commit message.

Sometimes, in some kinds of projects, the commit messages looks like this:

  JIRA: #1234

  Adjusted the FOOBAR parameter from 42 to 73.
To know the "why", you have to read the ticket; you will not find anything in the git log.

Re: Git log is not a changelog

#87
post #54
post #38

Earlier quoted context omitted.

To explain why a certain block of code exists. When the code came into existence is rarely that important. You just want to know why. Why does the code fence against a particular circumstance you didn't think should be possible? Why does it call out to something you think is unrelated? Those questions can be answered by a proper commit message.

Why don’t you put that as a comment on the code?

Because if 37 changes are done to the same 15 line function over time, the amount of comment material will dwarf the function. And most of it will pertain to historic versions of the function which are not what actually appears below the comment; a comment made 13 revisions ago makes sense for the 13-revision-old version of the function.

Re: Git log is not a changelog

#88
post #38

Earlier quoted context omitted.

To explain why a certain block of code exists. When the code came into existence is rarely that important. You just want to know why. Why does the code fence against a particular circumstance you didn't think should be possible? Why does it call out to something you think is unrelated? Those questions can be answered by a proper commit message.

Sometimes, in some kinds of projects, the commit messages looks like this: JIRA: #1234 Adjusted the FOOBAR parameter from 42 to 73. To know the "why", you have to read the ticket; you will not find anything in the git log.

Oh jeez, please do not make me run “git log” and then open a hundred tabs in an old bug tracker that may or may not still exist to figure out when a problem may have been introduced. I want code reviewers to insist on at least somewhat useful messages for us to skim at 3 AM.

Re: Git log is not a changelog

#89
post #54

Earlier quoted context omitted.

Why don’t you put that as a comment on the code?

Because if 37 changes are done to the same 15 line function over time, the amount of comment material will dwarf the function. And most of it will pertain to historic versions of the function which are not what actually appears below the comment; a comment made 13 revisions ago makes sense for the 13-revision-old version of the function.

You just update the comment?

Re: Git log is not a changelog

#90

Earlier quoted context omitted.

Let's say you have some code written 2 years ago. 2 months ago someone made a bug fix in the code replacing a few of the lines. How would you know from test, specs or examples which specific lines were modified and by whom? I don't get it.

Why would I want to do that? Usually if there's a problem I'll either write a new test or see if someone modified a test I thought was covering the case Usually people 'own' a file or part of the system so that wouldn't really be happening anyway

> Why would I want to do that?

Because sometimes we can learn from history. If a mistake was made at some point it can be good to understand why. Of course you can adopt the mindset that you don't care what ended up causing a bug, but learning from mistakes is a good thing.

> see if someone modified a test I thought was covering the case

How do you see if someone modified the test then? I feel like we are maybe misunderstanding eachother because to me, and seemingly most other commenter here, this is such an obvious no-brainer that it seems something is lost in the communication.

Post reply on HN