6 ms·

Look at the cpython history. There is a major change from Mercurial to Git. It's not that Mercurial doesn't support the "rebase" workflow. It does discourage

by nas 7y ago

Look at the cpython history. There is a major change from Mercurial to Git. It's not that Mercurial doesn't support the "rebase" workflow. It does discourage it though. Personally, I much prefer the "rebase your WIP changes, avoid merges" style. It is much easier to work with the resulting history.

Svoka 7y ago
I never got this argument. What the point of "clean history"? History is for log of work, not for being nice read.
- Cthulhu_ 7y ago
  So said log of work is not to be read? Why even bother with commit messages then? It might not be useful for you or your projects, but that's up to you. Linux is the other side of the coin though - they NEED to be able to read a commit from ten years ago, see what was changed (the diff), why it was changed, and by who it was changed and signed off. Take a look at their repository, e.g. via github for ease of access. Here's a random commit: https://github.com/torvalds/linux/commit/e1e54ec7fb55501c33b117c111cb0a045b8eded2 https://github.com/torvalds/linux/commit/e1e54ec7fb55501c33b.... Even with my complete lack of knowledge of kernel development, I can tell that the minor code change is backed up by a lot of reasoning and intent. But, it's a wholly different use case. Most applications I've worked with are basically webapps that will be thrown away within five years, where it's not as important.
  - nomel 7y ago
    > Why even bother with commit messages then? For me, it's all about understanding context of a change, the "why" (commit message) not "what" (code comments). I can run regression tests to find where things broke and, with the messages, have a good understanding of the context and mindset the developer was working in. In my editor, I can select some code and click "show history for selection" and get a complete log of what happened on those lines. If the commit messages are good, I'll have on understanding of the context of the change. Missing commit messages usually result in "I don't remember" type emails from the author when I inevitably ask what them why they made a change.
- rtpg 7y ago
  "Commits ordered by when I figured out a bug" has a lot less value than "Commits where changes are grouped by semantic logic". Stuff like git rebase don't work so well if you have a bunch of WIP busted commits as well. Maybe you don't commit that often, but people I work with (and myself) commit pretty often so it's easy to have just outright mistaken git commit messages like "fix X" followed by "actually fix X". going through a rebase to have "fix X" mean "fix X" will be great for the future debugging session with a git blame.
  - clktmr 7y ago
    In addition, it makes cherry picking bugfixes to older releases much easier.
  - stonogo 7y ago
    On the other hand, "fix x" followed by a couple lines of rationale, then "actually fix x" with a discussion of why the previous fix was wrong is more useful to someone trying to understand x.
    - rgoulter 7y ago
      I think the discussion is valuable. I think adding those insights to a wiki 'Pitfalls' page or whatever is valuable. From the top of my head, the cases where I'm looking at Git logs are: 1. Code Review. Most of the time I'm reviewing code is looking at a diff. But obviously one of "fix" and "actually fix" is redundant. A clean history also benefits if I want to focus in on one of the commits. 2. Annotation/Blame. If I'm debugging through some issue and looking at older changes, it's nice if coupled changes are in the same commit. A warts-and-all history has some advantages over rewriting git history (e.g. you could find patterns of where "actually fix" happens and try and improve those), but rewriting history makes the log a better communication tool.
    - rtpg 7y ago
      Yeah this is legitimate I think it’s maybe the difference between emotional truth and literal truth. The emotional truth is the valuable one so rebasing (which doesn’t mean squashing to one commit!) can mean you can clean out the noise and get something valuable.
- luxcem 7y ago
  If it's not readable you are not going to read it. A readable git history is really valuable. The day you'll use git bisect you will understand that.
- dahart 7y ago
  What’s the argument for messy work? History is something everyone on the team needs to use every day for working. Messy history on a large team can be like a thousand little paper cuts, it drains everyone’s time little by little, and it increases the probability of mistakes.
- jerf 7y ago
  As a codebase gets larger and older, git bisect becomes invaluable. If you have not used it, you don't know what you're missing. A pre-condition for git bisect working is that each commit must run well enough to successfully test for whatever behavior change is being tested for. Otherwise, you'll identify some commit where the code went from working to not working, but if it's just some idiotic typo instead of actually the change that you are looking for, you've lost. I'd rather have a git bisectable history that correctly reflects a steady progression of the product than one that records every typo some developer made for posterity. That I typo'ed a variable name in a version that never shipped to anybody and then had to commit "FIXUP" is not useful information. A clean commit that changes behavior, but is subsequently revealed to cause a regression against a test that won't be written for another two years, is incredibly valuable. Some of you say you don't get the appeal of a "clean" history; I say back I don't get the appeal of a pedantically historical view of history. I have never gone digging through some old history to figure out whether or not some particular piece of documentation was at some point in the past misspelled. Completely uninteresting. I have never cared about the process of how a particular thing was arrived at, with all the false starts, not to mention that if I did, trying to read a series of patches isn't how I'd want to do it. I have cared about being able to cherry-pick a single clean commit to backport some feature, I have cared about git bisect, and I have cared about the ability to revert a particular feature via "git revert" without having to figure out which discontinuous set of half-a-dozen patches need to be reverted because almost no commits from the past can be reverted without making fundamental breaks to the build, not for fundamental reasons, but because they introduce typos and break variable names and re-do accidental file deletions, etc. History as a log of work is way less interesting than history as a queryable and manipulable data structure representing the various mostly-valid states of your project, and the ability to manipulate those mostly-valid states at a project level. Composing two valid states of the project together to get a third is incredibly powerful, and when two valid states compose together to create an invalid state, there's real information of some kind there. This doesn't work if your history mostly consists of invalid states. Composing two invalid states of the project together to get another invalid state isn't a surprise, it produces and teaches nothing. This is why, whenever I can, I have a git pre-commit hook that checks the compile of everything and runs all my test cases. It's better for that to be the habit, and to have to occasionally bypass it for some reason, than for the default to be allowing any ol' commit to fundamentally break whatever. Doing it in a CI system is fine too; I do what I can to keep the local tests working but it's not always possible. The key is just that something is done to ensure validity is maintained.
- mrmuagi 7y ago
  History is extremely useful for being read. For backporting between trees, looking at historical development of a feature, to bisecting an introduced bug or regression.

by nas 7y ago

Svoka 7y ago

I never got this argument. What the point of "clean history"? History is for log of work, not for being nice read.

Cthulhu_ 7y ago
So said log of work is not to be read? Why even bother with commit messages then? It might not be useful for you or your projects, but that's up to you. Linux is the other side of the coin though - they NEED to be able to read a commit from ten years ago, see what was changed (the diff), why it was changed, and by who it was changed and signed off. Take a look at their repository, e.g. via github for ease of access. Here's a random commit: https://github.com/torvalds/linux/commit/e1e54ec7fb55501c33b117c111cb0a045b8eded2 https://github.com/torvalds/linux/commit/e1e54ec7fb55501c33b.... Even with my complete lack of knowledge of kernel development, I can tell that the minor code change is backed up by a lot of reasoning and intent. But, it's a wholly different use case. Most applications I've worked with are basically webapps that will be thrown away within five years, where it's not as important.
- nomel 7y ago
  > Why even bother with commit messages then? For me, it's all about understanding context of a change, the "why" (commit message) not "what" (code comments). I can run regression tests to find where things broke and, with the messages, have a good understanding of the context and mindset the developer was working in. In my editor, I can select some code and click "show history for selection" and get a complete log of what happened on those lines. If the commit messages are good, I'll have on understanding of the context of the change. Missing commit messages usually result in "I don't remember" type emails from the author when I inevitably ask what them why they made a change.
rtpg 7y ago
"Commits ordered by when I figured out a bug" has a lot less value than "Commits where changes are grouped by semantic logic". Stuff like git rebase don't work so well if you have a bunch of WIP busted commits as well. Maybe you don't commit that often, but people I work with (and myself) commit pretty often so it's easy to have just outright mistaken git commit messages like "fix X" followed by "actually fix X". going through a rebase to have "fix X" mean "fix X" will be great for the future debugging session with a git blame.
- clktmr 7y ago
  In addition, it makes cherry picking bugfixes to older releases much easier.
- stonogo 7y ago
  On the other hand, "fix x" followed by a couple lines of rationale, then "actually fix x" with a discussion of why the previous fix was wrong is more useful to someone trying to understand x.
  - rgoulter 7y ago
    I think the discussion is valuable. I think adding those insights to a wiki 'Pitfalls' page or whatever is valuable. From the top of my head, the cases where I'm looking at Git logs are: 1. Code Review. Most of the time I'm reviewing code is looking at a diff. But obviously one of "fix" and "actually fix" is redundant. A clean history also benefits if I want to focus in on one of the commits. 2. Annotation/Blame. If I'm debugging through some issue and looking at older changes, it's nice if coupled changes are in the same commit. A warts-and-all history has some advantages over rewriting git history (e.g. you could find patterns of where "actually fix" happens and try and improve those), but rewriting history makes the log a better communication tool.
  - rtpg 7y ago
    Yeah this is legitimate I think it’s maybe the difference between emotional truth and literal truth. The emotional truth is the valuable one so rebasing (which doesn’t mean squashing to one commit!) can mean you can clean out the noise and get something valuable.
luxcem 7y ago
If it's not readable you are not going to read it. A readable git history is really valuable. The day you'll use git bisect you will understand that.
dahart 7y ago
What’s the argument for messy work? History is something everyone on the team needs to use every day for working. Messy history on a large team can be like a thousand little paper cuts, it drains everyone’s time little by little, and it increases the probability of mistakes.
jerf 7y ago
As a codebase gets larger and older, git bisect becomes invaluable. If you have not used it, you don't know what you're missing. A pre-condition for git bisect working is that each commit must run well enough to successfully test for whatever behavior change is being tested for. Otherwise, you'll identify some commit where the code went from working to not working, but if it's just some idiotic typo instead of actually the change that you are looking for, you've lost. I'd rather have a git bisectable history that correctly reflects a steady progression of the product than one that records every typo some developer made for posterity. That I typo'ed a variable name in a version that never shipped to anybody and then had to commit "FIXUP" is not useful information. A clean commit that changes behavior, but is subsequently revealed to cause a regression against a test that won't be written for another two years, is incredibly valuable. Some of you say you don't get the appeal of a "clean" history; I say back I don't get the appeal of a pedantically historical view of history. I have never gone digging through some old history to figure out whether or not some particular piece of documentation was at some point in the past misspelled. Completely uninteresting. I have never cared about the process of how a particular thing was arrived at, with all the false starts, not to mention that if I did, trying to read a series of patches isn't how I'd want to do it. I have cared about being able to cherry-pick a single clean commit to backport some feature, I have cared about git bisect, and I have cared about the ability to revert a particular feature via "git revert" without having to figure out which discontinuous set of half-a-dozen patches need to be reverted because almost no commits from the past can be reverted without making fundamental breaks to the build, not for fundamental reasons, but because they introduce typos and break variable names and re-do accidental file deletions, etc. History as a log of work is way less interesting than history as a queryable and manipulable data structure representing the various mostly-valid states of your project, and the ability to manipulate those mostly-valid states at a project level. Composing two valid states of the project together to get a third is incredibly powerful, and when two valid states compose together to create an invalid state, there's real information of some kind there. This doesn't work if your history mostly consists of invalid states. Composing two invalid states of the project together to get another invalid state isn't a surprise, it produces and teaches nothing. This is why, whenever I can, I have a git pre-commit hook that checks the compile of everything and runs all my test cases. It's better for that to be the habit, and to have to occasionally bypass it for some reason, than for the default to be allowing any ol' commit to fundamentally break whatever. Doing it in a CI system is fine too; I do what I can to keep the local tests working but it's not always possible. The key is just that something is done to ensure validity is maintained.
mrmuagi 7y ago
History is extremely useful for being read. For backporting between trees, looking at historical development of a feature, to bisecting an introduced bug or regression.