5 ms·

As long as your final commits are logical you don't lose anything. You need clean commits on the history to be able to understand the code later on. During cod

As long as your final commits are logical you don't lose anything. You need clean commits on the history to be able to understand the code later on. During code review at a later time, the history of the experimentation is useless once you find several commits that touch the same code before settling on a final version.

tootie 13y ago
> 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.
- MatmaRex 13y ago
  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.
- crististm 13y ago
  What do you think is easier for the next guy? 1) three commits that do: - a = 1; - a = 7; - a = 3; or 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.
  - jlgreco 13y ago
    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.
  - tootie 13y ago
    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.
    - amboar 13y ago
      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?
      - tootie 13y ago
        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.
        amboar 13y ago
        Interesting. What's the rough order of magnitude of the "end state" patch size? 50, 500, 5000 lines?
    - crististm 13y ago
      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.
    - _prometheus 13y ago
      > 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_Convention http://en.wikipedia.org/wiki/Atomic_commit#Atomic_Commit_Con...
sanderjd 13y ago
> You need clean commits on the history to be able to understand the code later on. I think this whole debate hinges on peoples' view of that sentence. Sometimes clean history helps comprehensibility and sometimes it obscures things. I think the amount to which each is true varies author to author, reader to reader, and project to project.
- _prometheus 13y ago
  > I think this whole debate hinges on peoples' view of that sentence. Prescient observation. How does clean history obscure things though? You mean as failed experiments get removed? Important things ought to be mentioned in commit messages. Relevant things to document can be showcased like "Tried X but it turns out Y is better because Z." I often find that code alone is not enough to describe why something did or didn't work. One ends up having to explain in commit messages anyway.
  - sanderjd 13y ago
    > I often find that code alone is not enough to describe why something did or didn't work. Me too. And I also often find that commit messages alone are not enough to describe why something did or didn't work. Code and commit messages both help. "Clean history" can obscure things when it leaves out information about the often messy process of creating the software. It's impossible to know ahead of time what information will and will not be useful when attempting to grok a piece of code in the future, so sometimes it makes sense to err on the side of more information, instead of less.
dreamdu5t 13y ago
You can have both. Use tags to mark features and releases. That is what tags are for!

tootie 13y ago

> 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.

MatmaRex 13y ago
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.
crististm 13y ago
What do you think is easier for the next guy? 1) three commits that do: - a = 1; - a = 7; - a = 3; or 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.
- jlgreco 13y ago
  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.
- tootie 13y ago
  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.
  - amboar 13y ago
    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?
    - tootie 13y ago
      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.
      - amboar 13y ago
        Interesting. What's the rough order of magnitude of the "end state" patch size? 50, 500, 5000 lines?
  - crististm 13y ago
    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.
  - _prometheus 13y ago
    > 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_Convention http://en.wikipedia.org/wiki/Atomic_commit#Atomic_Commit_Con...

sanderjd 13y ago

> You need clean commits on the history to be able to understand the code later on. I think this whole debate hinges on peoples' view of that sentence. Sometimes clean history helps comprehensibility and sometimes it obscures things. I think the amount to which each is true varies author to author, reader to reader, and project to project.

_prometheus 13y ago
> I think this whole debate hinges on peoples' view of that sentence. Prescient observation. How does clean history obscure things though? You mean as failed experiments get removed? Important things ought to be mentioned in commit messages. Relevant things to document can be showcased like "Tried X but it turns out Y is better because Z." I often find that code alone is not enough to describe why something did or didn't work. One ends up having to explain in commit messages anyway.
- sanderjd 13y ago
  > I often find that code alone is not enough to describe why something did or didn't work. Me too. And I also often find that commit messages alone are not enough to describe why something did or didn't work. Code and commit messages both help. "Clean history" can obscure things when it leaves out information about the often messy process of creating the software. It's impossible to know ahead of time what information will and will not be useful when attempting to grok a piece of code in the future, so sometimes it makes sense to err on the side of more information, instead of less.

dreamdu5t 13y ago

You can have both. Use tags to mark features and releases. That is what tags are for!