[usrusr]

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.

[jacobegold]

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)

[91edec]

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]

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]

Branches are not cognitively free. Searching through the haystack of hundreds of branches to find a particular needle is a pain.

[cplusplusfellow]

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.