5 ms·
> The unsafe versions of these things literally throw out history and replace it with a fiction that whoever did the final operation wrote everything, or that t
by kelnos 7mo ago
> The unsafe versions of these things literally throw out history and replace it with a fiction that whoever did the final operation wrote everything, or that the original author wrote something possibly very divergent from what they actually wrote.
When I'm rebasing my own work and editing history, that's exactly what I'm looking to accomplish, though.
- rmunn 7mo agoThe team I work for tends to use GitHub's "Squash and merge" button a lot. I find it to be the best of both worlds: the `develop` branch gets a single commit per PR, with a summary of what was done (I always edit the summary commit message and reduce it from a copy of 20 commit messages down to just the most important 4-5, deleting the entirety of messages like "fixup" or "address review comments"). But the PR on GitHub also preserves the history of the commits, so anyone who wants to look at the messy commit history can follow the PR link and see the actual commits. I'm sure there are other Git forges that would support a similar workflow, with a "Squash and Merge" button or equivalent, but my team hasn't felt any need to migrate away from GitHub so I've never yet investigated that in detail. Only downside I've found to this workflow is that it would make it harder to migrate to a different Git forge in the future: unless you're very careful with the migration, the PR numbers are likely to be different (perhaps resetting at 1, even) and the other forge won't end up with the commits that are on GitHub's copy of the repo but no longer on any active branch (we also use the "auto-delete branches when you hit the merge button" option). But it would still be possible for a migration tool to handle this correctly: look at all PRs on GitHub, grab the commits from them, and migrate them to Merge Requests on the new forge.
- anonymars 7mo agoIt boggles my mind that instead of this being a UI projection, git instead ingrains a process where developers habitually destroy their history (and bisection options, and merge conflict resolution), therein loading an additional footgun that goes off every now and again when it turns out a now-squashed branch was the basis of (or merged into) some other branch
- rmunn 7mo agoYes, a good Git log viewer that would auto-squash branches down to a summary, and allow "expanding" them, would be useful. But the way branching and merging creates confusing train-track graphs is IMHO one of the reasons why many teams end up using the squash-and-merge workflow. There's definitely room for improvement there...
- anonymars 7mo agoFor sure. It just bugs me that we're stuck between two bad options. Now let's also talk about renames...
- kadoban 7mo agoGit doesn't do that. People needlessly destroying history do that. Git will happily let you merge branches and preserve the history there. GP seems to like that history being in PRs only on github instead. I don't get why, that just seems worse to me.
- plasticchris 7mo agoThe why is that most people when given the merge option don’t clean up their history so you end up with tons of garbage fix up commits.
- DiggyJohnson 7mo agoThat is an issue of ignorance, not laziness. It’s not obvious at all to an average developer that only uses `add/commit/merge/fetch/push/pull/rebase/restore/reset` that they can manipulate their change history.
- plasticchris 7mo agoThe cause stops mattering after a while, either you have to go on a full time campaign to educate people… or switch the setting to rebase and squash and be done with it.