51–59 of 59 posts
Amazing that we don't yet have a source control solution that's simpler than git. It should not be a barrier to entry for our profession.
For ardour, we almost never squash commits because we prefer our (always linear) git history to show the actually "story" of a branch's development. There are two exceptions. 1. branch developer suffered from several "thinkos" along the way, the branch doesn't contain that many changes, and there's simply no benefit to seeing the contrast between the initial (mistaken) changes and the final result. 2. the branch comm…
Earlier quoted context omitted.
> If I get a PR to review I want the set of commits to be clean and represent logical changes. No “oops” commits. +100. Though every time this comes up on HN you would be surprised by how much some people just vehemently disagree. I will also add another requirement - all unit tests should pass at each commit in the PR. That way, you can use the rebase strategy to merge and you would still be able to bisect.
Passing unit tests on each commit is only a realistic goal if developers can run all tests locally in less than (say) an hour. If the test suite is ten hours and you have ten commits on a branch then it quickly becomes silly to bog down your build servers (or cloud bills) with building and testing the intermediate commits over 90h. Using your own machine to do it (blocking it from doing other work) is obviously not a…
That's a fair point, but I would say that if you encourage your devs to make each commit logical, meaningful and self contained, this is worth the extra cost.
Also, you don't need to run ALL unit tests - just the ones affected by commit you are testing. This of course requires a build system with good dependency analysis.
For ardour, we almost never squash commits because we prefer our (always linear) git history to show the actually "story" of a branch's development. There are two exceptions. 1. branch developer suffered from several "thinkos" along the way, the branch doesn't contain that many changes, and there's simply no benefit to seeing the contrast between the initial (mistaken) changes and the final result. 2. the branch comm…
About half the time I get stuck during squashing and rebasing I end up trashing everything, re-cloning the repo and just doing one commit with all my changes from the other branch. Much easier than trying to figure out what series of errors or issues git is having. Fundamentally, this is my fault - I don’t have a good mental model of git, and even when I do have a solid understanding of what I’m attempting to achieve…
'git reflog' is your friend as it keeps a history of local operations, then you can do a 'git reset --hard HEAD@{X}' where X is the point in your reflog before the rebase started.
For ardour, we almost never squash commits because we prefer our (always linear) git history to show the actually "story" of a branch's development. There are two exceptions. 1. branch developer suffered from several "thinkos" along the way, the branch doesn't contain that many changes, and there's simply no benefit to seeing the contrast between the initial (mistaken) changes and the final result. 2. the branch comm…
You have no way of knowing if a developer squashed locally...
Semi-related: my favorite dev tool is diff2html I aliased `diff` to open up my browser showing me the full diff of what I'm working on - super useful! https://diff2html.xyz/
I recently started using `git commit --fixup` which I really like. It lets you take the current changes and apply them to a commit which is not the most recent (in a fairly roundabout way). It's good for when I have a stack of diffs and want to make changes to multiple commits at once. (Note this is a pretty advanced technique, if you're not super comfortable with `git rebase -i` I wouldn't bother even trying to unde…
10+ years and I still don’t understand why developers and orgs think it’s necessary to squash and rebase.
I've seen two main arguments to that workflow. One argument, and which I hear often, is that they want to keep the git history clean. The other argument is that keeping things rebased & squashed allows you to do reverts easily. I personally don't mind the merge commits cluttering the history, and especially when working on a longer lived branch I will always prefer merging-in changes rather than constantly rebasing a…
git revert -m 1 $commit
You can also visualize a clean history with merge commits.
git log —-first-parent
The only argument I’ve heard that holds weight is that GitHub’s UI squashes the merge commit history into a linear view.