5 ms·

I'm a fan of the workflow where the PR gets squashed in the upstream git repo, but the individual commits are preserved in the PR in the code review tool. I fee

I'm a fan of the workflow where the PR gets squashed in the upstream git repo, but the individual commits are preserved in the PR in the code review tool. I feel that Phabricator handles this well.

easton 3y ago
GitHub and Azure DevOps also do that, you just need to know where to look. I don’t mind squashing either, unless I’m being really intentional or rewriting my history my intermediate commits couldn’t be reverted without leaving stuff broken (totally a me problem of course).
- hamburglar 3y ago
  Intermediate commits being snapshots of “broken” state isn’t a problem at all. When I quit for the day, I commit, broken or not, and pick it up in the morning. I want to be able to drop my laptop in a puddle and still pick up where I left off when I get a new one.
  - iimblack 3y ago
    I think the problem is putting those broken commits into the trunk. Ideally you want to clean up your commits so if you need to revert you don’t accidentally break your build and so reading thru history isn’t awful.
    - hamburglar 3y ago
      Nobody anywhere suggested putting broken commits in trunk. This is why branches exist.
usrusr 3y ago
But does that still lose the source commit long term? What I'd love to have is a mechanism that keeps references to the pre-squash commits at blame granularity, allowing one to dig deeper into the commit messages associated with a given line. Kind of like a sourcemap, but for squash instead of transpile.
- 91edec 3y ago
  When you squash merge on github the new commit references the old PR. If you don't delete branches on merge you would keep the commit history on that branch, but then you have to battle with branchs persisting forever.
  - cplusplusfellow 3y ago
    Branches are mostly free, so this isn’t a problem if they are properly named. “try-again-something5” doesn’t cut it but “$ticket-at-least-five-words-here” does.
    - TheCleric 3y ago
      Branches are not cognitively free. Searching through the haystack of hundreds of branches to find a particular needle is a pain.
      - cplusplusfellow 3y ago
        You’re translating the problem from : searching through branches that are named according to their ticket and what they are meant to accomplish to: complex and not-context-free git bisect.
- jacobegold 3y ago
  You don't lose it long term if you're using GitHub PRs — GitHub keeps the "reflog" (quoted because I imagine their implementation may not actually use reflog) of the branch indefinitely, even after force pushes. Graphite (built to replicate the Phabricator workflow) enables viewing and diffing these versions. (disclaimer, I helped build this)

I'm a fan of the workflow where the PR gets squashed in the upstream git repo, but the individual commits are preserved in the PR in the code review tool. I feel that Phabricator handles this well.

easton 3y ago

GitHub and Azure DevOps also do that, you just need to know where to look. I don’t mind squashing either, unless I’m being really intentional or rewriting my history my intermediate commits couldn’t be reverted without leaving stuff broken (totally a me problem of course).

hamburglar 3y ago
Intermediate commits being snapshots of “broken” state isn’t a problem at all. When I quit for the day, I commit, broken or not, and pick it up in the morning. I want to be able to drop my laptop in a puddle and still pick up where I left off when I get a new one.
- iimblack 3y ago
  I think the problem is putting those broken commits into the trunk. Ideally you want to clean up your commits so if you need to revert you don’t accidentally break your build and so reading thru history isn’t awful.
  - hamburglar 3y ago
    Nobody anywhere suggested putting broken commits in trunk. This is why branches exist.

usrusr 3y ago

But does that still lose the source commit long term? What I'd love to have is a mechanism that keeps references to the pre-squash commits at blame granularity, allowing one to dig deeper into the commit messages associated with a given line. Kind of like a sourcemap, but for squash instead of transpile.

91edec 3y ago
When you squash merge on github the new commit references the old PR. If you don't delete branches on merge you would keep the commit history on that branch, but then you have to battle with branchs persisting forever.
- cplusplusfellow 3y ago
  Branches are mostly free, so this isn’t a problem if they are properly named. “try-again-something5” doesn’t cut it but “$ticket-at-least-five-words-here” does.
  - TheCleric 3y ago
    Branches are not cognitively free. Searching through the haystack of hundreds of branches to find a particular needle is a pain.
    - cplusplusfellow 3y ago
      You’re translating the problem from : searching through branches that are named according to their ticket and what they are meant to accomplish to: complex and not-context-free git bisect.
jacobegold 3y ago
You don't lose it long term if you're using GitHub PRs — GitHub keeps the "reflog" (quoted because I imagine their implementation may not actually use reflog) of the branch indefinitely, even after force pushes. Graphite (built to replicate the Phabricator workflow) enables viewing and diffing these versions. (disclaimer, I helped build this)