Hacker News new | comments | show | ask | jobs | submit login

> You need clean commits on the history to be able to understand the code later on.

Really? That seems like an extraordinarily obtuse way to understand code. I would think comments directly the source files would be more useful. Commit history shows how they arrived at that result and that's what I would rather see there.

What do you think is easier for the next guy? 1) three commits that do:

- a = 1;

- a = 7;

- a = 3;


2) one commit that says:

a = 3;

My point is that experimentation is slightly different from changing your mind about the whole implementation. It is the same as writing your homework. You have a separate piece of paper where you make your experiments.

Not to mention that in practice, if this sort of history cleaning is forbidden then people will just attempt to not commit those first two lines, meaning that they are not getting the full benefit of version control.

When does the "next guy" ever look at revision history to see what's going on? I only ever look at the current state. If I want to see how it diverged from my last commit or the last commit before whatever milestone or release, I will diff the current version against that version ignoring every commit in between.

> When does the "next guy" ever look at revision history to see what's going on?

_All the time_. I read all the commits in the codebase I'm responsible for. I need to keep track of what people are doing and how the system is changing. This is also on top of the need for code review and ensuring each patch is correct.

Check out http://en.wikipedia.org/wiki/Atomic_commit#Atomic_Commit_Con...

I do that all the time with code that I don't understand. The commit message is the last resort of getting a human to talk to you when the comments are missing.

Given one of your other comments here, I get the impression you don't use code review tools much, eg Gerrit. Is that the case?

Not on most projects, no. We are on my current project and the review tool is based on tasks, not commits and can review multiple commits in a single session if they are all related to the same task. Regardless, I am only ever reviewing the end state.

Interesting. What's the rough order of magnitude of the "end state" patch size? 50, 500, 5000 lines?

Commit messages I write are often several paragraphs long (and sometimes that's for a one-line change). Including all of the information in comments is not always viable.

Applications are open for YC Winter 2018

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact