11 ms·

When I am working on a feature branch, I often find myself committing experiments, that I possibly undo later in the branch. I don't always focus on making "inc

When I am working on a feature branch, I often find myself committing experiments, that I possibly undo later in the branch. I don't always focus on making "incremental, atomic" commits, because I am usually focused on the code. When the feature is done (but before I merge it into master), I will usually go through and clean up my meanderings, and turn them into "incremental, atomic" commits, so that my teammates don't need to deal with my meanderings if they ever need to run a bisect over my code. You may say I'm doing it wrong, and that's fine, but it works for me.

tootie 13y ago
If you rebase aren't you destroying that history of experimentation? I feel like this is destroying the whole idea of a VCS as a safety net and making developers self-conscious about something that supposed to tolerant of mistakes.
- crististm 13y ago
  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?
  - 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!
- a1k0n 13y ago
  You can always keep the un-rebased branch around if you want to preserve the history somewhere, and then squash the commits down to a smaller number on top of master. That solves the safety net problem, and master keeps its sanitized history. This is what I do and it's kind of required when you're using e.g. gerrit code reviews.
- Daishiman 13y ago
  Why do you care about the history of dead-end experiments polluting the history of the specific final features being implemented and incorporated into the mainline?
  - untothebreach 13y ago
    Exactly this. I don't mind leaving the history of experiments in if they lead fairly logically and cleanly to the final product, but sometimes I will have 2 or 3 "WIP" commits in a row, that turn out to be completely irrelevant to the final product.
  - sanderjd 13y ago
    I see both sides of this, but on my own team, where we are all meant to be experts on the project, I really like to be able to see the experiments, because there's a reasonable chance I'll be trying something similar to or perhaps inspired by those throwaway experiments at some point. I think there is a different trade-off in open source projects, where it's more helpful to have a history that isn't confusing to newcomers.
    - phillmv 13y ago
      I end up with a lot of "Interim commit on foobarbaz" because I'm leaving work and want to push my code just-in-case. Refolding those into "foobarbaz: feature 1" is a lot nicer.
      - dreamdu5t 13y ago
        The central repo is not meant as a place to backup your working tree. That's the point of git stash, and local branches. If you're worried about losing your working tree, back it up!
    - Daishiman 13y ago
      Then have them push the experimental branches and perform the rebase on a temporary branch, but it's still no excuse to have a clean feature history.
- lambda 13y ago
  Cleaning up your history before merging is important. For one, before you merge you should usually have someone do code review. No one wants to do a code review on a branch that has a bunch of false starts, typo fixups, debug print statements being added and removed, and so on. Code reviewing a branch that breaks something and then fixes it three commits later is a real pain; you sit there puzzling over the first commit, wondering how it could possibly work, and writing up a big explanation for why they need to fix something, then you go on to a later commit and realize they already fixed it. Furthermore, dirty branches lose you a lot of the power that having a good, clean history gives you. When you do a blame on a line of code, to figure out when the last change was, do you want to see the "fix whitespace to match style guide" commit that someone insert in the branch at the end, or the actual meaningful change that occurred earlier? If you don't squash your commits to deal with these kinds of issues, you lose a lot of the power and convenience that good history gives you. There's more. One of Git's most powerful tools is bisect, but even in a VCS without an automated bisect, doing it manually can be useful to (I've done this in SVN before). If you have a regression, but have no idea what caused it, it can be very useful to bisect your commits; find a known good version and a known bad version, then go to the commit halfway in between, test that, and depending on whether that commit is good or bad, test the one halfway between that and the known good or known bad commit. Keep doing this until you find the commit that broke your code. But this process is seriously impeded if you have a bunch of half-done commits that implement a part of a feature but break something else that's fixed up three commits later. The "history of experimentation" nature of VCS history is just not all that interesting. Think of your VCS history more as an extended form of comments, that document why everything is the way it is. If you actually wrote comments on every line describing why you had changed it in a particular way every time you changed it, your code would wind up being more than 90% comments in not too long. Most of the time, you don't need to see this; but when you are left wondering "hmm, why is this the way it is?", good history is invaluable. The experimental changes in between aren't all that useful; if you got any information from them, then feel free to summarize that in the cleaned up commit message after you've squashed them out. Now, that's not to say that you should always produce perfect history while working on a branch. Feel free, when you're in exploratory coding mode, to make lots of checkpoint commits, experiments, and so on. Just clean it up before you present it for review and merge. The nice thing about Git is that you have your own local branches that no one else ever has to see, clean things up quickly and easily with "git rebase -i", and present a much nicer history when it's ready for merge.
- e40 13y ago
  I like lambda's answer, to which I'll add: You have NEVER finished work on a feature and you look at the history and there are 10's of commits with crappy commit messages and extremely minor changes? If so, good for you. Not so for me. I don't always squash ALL commits on my feature branch, but I often remove a good number, so the history looks helpful for my future self.
- halfninety 13y ago
  You can have the best of both worlds, just backup your feature head before rebasing.
coherentpony 13y ago
>When I am working on a feature branch, I often find myself committing experiments, That's exactly what `git branch` is for. For experimentation. >that I possibly undo later in the branch. That's exactly what `git branch -D` is for. Or even just `git checkout` and leave the branch there. That way if you ever change your mind you can revisit it.

tootie 13y ago

If you rebase aren't you destroying that history of experimentation? I feel like this is destroying the whole idea of a VCS as a safety net and making developers self-conscious about something that supposed to tolerant of mistakes.

crististm 13y ago
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?
- 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!
a1k0n 13y ago
You can always keep the un-rebased branch around if you want to preserve the history somewhere, and then squash the commits down to a smaller number on top of master. That solves the safety net problem, and master keeps its sanitized history. This is what I do and it's kind of required when you're using e.g. gerrit code reviews.
Daishiman 13y ago
Why do you care about the history of dead-end experiments polluting the history of the specific final features being implemented and incorporated into the mainline?
- untothebreach 13y ago
  Exactly this. I don't mind leaving the history of experiments in if they lead fairly logically and cleanly to the final product, but sometimes I will have 2 or 3 "WIP" commits in a row, that turn out to be completely irrelevant to the final product.
- sanderjd 13y ago
  I see both sides of this, but on my own team, where we are all meant to be experts on the project, I really like to be able to see the experiments, because there's a reasonable chance I'll be trying something similar to or perhaps inspired by those throwaway experiments at some point. I think there is a different trade-off in open source projects, where it's more helpful to have a history that isn't confusing to newcomers.
  - phillmv 13y ago
    I end up with a lot of "Interim commit on foobarbaz" because I'm leaving work and want to push my code just-in-case. Refolding those into "foobarbaz: feature 1" is a lot nicer.
    - dreamdu5t 13y ago
      The central repo is not meant as a place to backup your working tree. That's the point of git stash, and local branches. If you're worried about losing your working tree, back it up!
  - Daishiman 13y ago
    Then have them push the experimental branches and perform the rebase on a temporary branch, but it's still no excuse to have a clean feature history.
lambda 13y ago
Cleaning up your history before merging is important. For one, before you merge you should usually have someone do code review. No one wants to do a code review on a branch that has a bunch of false starts, typo fixups, debug print statements being added and removed, and so on. Code reviewing a branch that breaks something and then fixes it three commits later is a real pain; you sit there puzzling over the first commit, wondering how it could possibly work, and writing up a big explanation for why they need to fix something, then you go on to a later commit and realize they already fixed it. Furthermore, dirty branches lose you a lot of the power that having a good, clean history gives you. When you do a blame on a line of code, to figure out when the last change was, do you want to see the "fix whitespace to match style guide" commit that someone insert in the branch at the end, or the actual meaningful change that occurred earlier? If you don't squash your commits to deal with these kinds of issues, you lose a lot of the power and convenience that good history gives you. There's more. One of Git's most powerful tools is bisect, but even in a VCS without an automated bisect, doing it manually can be useful to (I've done this in SVN before). If you have a regression, but have no idea what caused it, it can be very useful to bisect your commits; find a known good version and a known bad version, then go to the commit halfway in between, test that, and depending on whether that commit is good or bad, test the one halfway between that and the known good or known bad commit. Keep doing this until you find the commit that broke your code. But this process is seriously impeded if you have a bunch of half-done commits that implement a part of a feature but break something else that's fixed up three commits later. The "history of experimentation" nature of VCS history is just not all that interesting. Think of your VCS history more as an extended form of comments, that document why everything is the way it is. If you actually wrote comments on every line describing why you had changed it in a particular way every time you changed it, your code would wind up being more than 90% comments in not too long. Most of the time, you don't need to see this; but when you are left wondering "hmm, why is this the way it is?", good history is invaluable. The experimental changes in between aren't all that useful; if you got any information from them, then feel free to summarize that in the cleaned up commit message after you've squashed them out. Now, that's not to say that you should always produce perfect history while working on a branch. Feel free, when you're in exploratory coding mode, to make lots of checkpoint commits, experiments, and so on. Just clean it up before you present it for review and merge. The nice thing about Git is that you have your own local branches that no one else ever has to see, clean things up quickly and easily with "git rebase -i", and present a much nicer history when it's ready for merge.
e40 13y ago
I like lambda's answer, to which I'll add: You have NEVER finished work on a feature and you look at the history and there are 10's of commits with crappy commit messages and extremely minor changes? If so, good for you. Not so for me. I don't always squash ALL commits on my feature branch, but I often remove a good number, so the history looks helpful for my future self.
halfninety 13y ago
You can have the best of both worlds, just backup your feature head before rebasing.

coherentpony 13y ago

>When I am working on a feature branch, I often find myself committing experiments, That's exactly what `git branch` is for. For experimentation. >that I possibly undo later in the branch. That's exactly what `git branch -D` is for. Or even just `git checkout` and leave the branch there. That way if you ever change your mind you can revisit it.