4 ms·

Let me expand on this with a link to the article "Rebase Considered Harmful" [0]. I also prefer Fossil to Git whenever possible, especially for small or person

Let me expand on this with a link to the article "Rebase Considered Harmful" [0]. I also prefer Fossil to Git whenever possible, especially for small or personal projects. [0] https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md

fc417fc802 9mo ago
> Surely a better approach is to record the complete ancestry of every check-in but then fix the tool to show a "clean" history in those instances where a simplified display is desirable and edifying From your link. The actual issue that people ought to be discussing in this comment section imo.
- sigseg1v 9mo ago
  THIS is the hill I will die on. Why do we advocate destroying information/data about the dev process when in reality we need to solve a UI/display issue? The amount of times in the last 15ish years I've solved something by looking back at the history and piecing together what happened (eg. refactor from A to B as part of a PR, then tweak B to eventually become C before getting it merged, but where there are important details that only resulted because of B, and you don't realize they are important until 2 years later) is high enough that I consider it very poor practice to remove the intermediate commits that actually track the software development process.
  - stouset 9mo ago
    Because nobody cares about the dev process. The number of times I’ve looked back in the history and seen a branch with a series of twenty commits labeled “fix thing”, “oops”, “typo”, “remove thing I tried that didn’t work”, or just a chain of WIP WIP WIP WIP is useless, irritating, and pointless. One commit per logical change. One merge per larger conceptual change. I will rewrite my actual dev process so that individual commits can be reviewed as small, independent PRs when possible, and so that bigger PRs can be reviewed commit-by-commit to understand the whole. Because I care about my reviewers, and because I want to review code like this. Care about your goddamn craft, even just a little bit.
- rendaw 9mo ago
  Isn't this just `--first-parent`? I think that should probably be the default in git. Maybe the only way this will happen is with a new SCM. But the git authors are adamant that there's no convention for linearity, and somehow extended that to why there shouldn't be a "theirs" merge strategy to mirror "ours" (writing it out it makes even less sense, since "theirs" is what you'd want in a first-parent-linear repo, not "ours").

fc417fc802 9mo ago

> Surely a better approach is to record the complete ancestry of every check-in but then fix the tool to show a "clean" history in those instances where a simplified display is desirable and edifying From your link. The actual issue that people ought to be discussing in this comment section imo.

sigseg1v 9mo ago
THIS is the hill I will die on. Why do we advocate destroying information/data about the dev process when in reality we need to solve a UI/display issue? The amount of times in the last 15ish years I've solved something by looking back at the history and piecing together what happened (eg. refactor from A to B as part of a PR, then tweak B to eventually become C before getting it merged, but where there are important details that only resulted because of B, and you don't realize they are important until 2 years later) is high enough that I consider it very poor practice to remove the intermediate commits that actually track the software development process.
- stouset 9mo ago
  Because nobody cares about the dev process. The number of times I’ve looked back in the history and seen a branch with a series of twenty commits labeled “fix thing”, “oops”, “typo”, “remove thing I tried that didn’t work”, or just a chain of WIP WIP WIP WIP is useless, irritating, and pointless. One commit per logical change. One merge per larger conceptual change. I will rewrite my actual dev process so that individual commits can be reviewed as small, independent PRs when possible, and so that bigger PRs can be reviewed commit-by-commit to understand the whole. Because I care about my reviewers, and because I want to review code like this. Care about your goddamn craft, even just a little bit.
rendaw 9mo ago
Isn't this just `--first-parent`? I think that should probably be the default in git. Maybe the only way this will happen is with a new SCM. But the git authors are adamant that there's no convention for linearity, and somehow extended that to why there shouldn't be a "theirs" merge strategy to mirror "ours" (writing it out it makes even less sense, since "theirs" is what you'd want in a first-parent-linear repo, not "ours").