3 ms·

Fixing history enables powerful second level tools , such as bisect and cherry pick. Being able to pinpoint a problem to an exact commit is incredibly powerful

Fixing history enables powerful second level tools , such as bisect and cherry pick. Being able to pinpoint a problem to an exact commit is incredibly powerful for debugging, but it does require your commits to be as healthy as possible. If you fix a bug 10 commits after it was introduced , now the 10 commits between them are harder to work with; you always have to keep in mind that unrelated bug. And cherry picking is lovely between branches , but if a commit introduced a bug and another fixes it, now you always have to cherry pick them together. Easier to fix it and keep them atomic. A clean git history is not a vanity project. It can be used as a tool in further code building.

mixmastamyk 7y ago
Bisect still works anyway. For non-huge projects, all this obsession with tool minutiae is a waste of time. As mentioned by another poster, the fact that a whole website is needed to explain the concept illustrates the design and UI failure. This is an uphill battle that can't be won until a next-generation interface becomes usable by mortals. If that can't be done due to complexity, it's a lost cause for average developers paid for delivering business value.
- zemo 7y ago
  You're talking about a UI failure but you're not actually considering the entire experience. Reading the history of the project is a big part of the experience, especially for people in team lead roles. How much of your experience is writing code versus reading code? A merge-oriented workflow often results in a history that is deeply confusing to read. The only part of the experience that you're considering is the authorship of commits, not the utilization of the project's history. I've found a rebase-oriented workflow to result in a significantly more usable repository inasmuch as the history is significantly easier to understand.
  - mixmastamyk 7y ago
    History has been useful to me at a high level, inspecting grains of sand at the beach, not so much. I can imagine it might be useful to some like linux kernel devs, but nowhere I've ever worked over a long career.
    - zemo 7y ago
      it's not "inspecting grains of sand". If you have any number of developers worth talking about, merge-oriented workflows can create incredibly unwieldly git histories very quickly. I'm talking about, at a very high level, just understanding the history of the project. If you have five feature branches going on, and your developers are all committing on a regular basis, understanding the history and cadence of your project work based on the git history is incredibly difficult when the events of the separate feature branches are all intermingled. Your comparison is not apt in many ways. For one thing, open-source governance is extremely different than managing private codebases maintained by a single company. Nobody in open-source governance is reading git histories to figure out whether employees are struggling, who is performing, who is not performing, who is overworking, where the project is, whether or not people are duplicating their efforts, how to report progress to clients, etc. And besides, the Linux kernel uses an email-based, merge-oriented workflow anyway. Kernel patches are submitted via email. That's not at all representative of any company that I have ever worked for or any company that I know of. The Linux kernel history also has a network graph that is literally unviewable on Github because it's so complex. Again, not representative of 95% of the work for 95% of users on 95% of projects.
      - mixmastamyk 7y ago
        It's easy enough to select commits from one user, or squash whole branches. Our devs are judged on completed features they deliver at acceptable quality, not their commit history. I'm not saying you shouldn't care, just that I don't believe this strategy will become mainstream unless it gets much easier to understand and use.

mixmastamyk 7y ago

Bisect still works anyway. For non-huge projects, all this obsession with tool minutiae is a waste of time. As mentioned by another poster, the fact that a whole website is needed to explain the concept illustrates the design and UI failure. This is an uphill battle that can't be won until a next-generation interface becomes usable by mortals. If that can't be done due to complexity, it's a lost cause for average developers paid for delivering business value.

zemo 7y ago
You're talking about a UI failure but you're not actually considering the entire experience. Reading the history of the project is a big part of the experience, especially for people in team lead roles. How much of your experience is writing code versus reading code? A merge-oriented workflow often results in a history that is deeply confusing to read. The only part of the experience that you're considering is the authorship of commits, not the utilization of the project's history. I've found a rebase-oriented workflow to result in a significantly more usable repository inasmuch as the history is significantly easier to understand.
- mixmastamyk 7y ago
  History has been useful to me at a high level, inspecting grains of sand at the beach, not so much. I can imagine it might be useful to some like linux kernel devs, but nowhere I've ever worked over a long career.
  - zemo 7y ago
    it's not "inspecting grains of sand". If you have any number of developers worth talking about, merge-oriented workflows can create incredibly unwieldly git histories very quickly. I'm talking about, at a very high level, just understanding the history of the project. If you have five feature branches going on, and your developers are all committing on a regular basis, understanding the history and cadence of your project work based on the git history is incredibly difficult when the events of the separate feature branches are all intermingled. Your comparison is not apt in many ways. For one thing, open-source governance is extremely different than managing private codebases maintained by a single company. Nobody in open-source governance is reading git histories to figure out whether employees are struggling, who is performing, who is not performing, who is overworking, where the project is, whether or not people are duplicating their efforts, how to report progress to clients, etc. And besides, the Linux kernel uses an email-based, merge-oriented workflow anyway. Kernel patches are submitted via email. That's not at all representative of any company that I have ever worked for or any company that I know of. The Linux kernel history also has a network graph that is literally unviewable on Github because it's so complex. Again, not representative of 95% of the work for 95% of users on 95% of projects.
    - mixmastamyk 7y ago
      It's easy enough to select commits from one user, or squash whole branches. Our devs are judged on completed features they deliver at acceptable quality, not their commit history. I'm not saying you shouldn't care, just that I don't believe this strategy will become mainstream unless it gets much easier to understand and use.