Gregory's Servercombining branches
 20 comments
 @b0rk This needs to be expressed more succinctly, but a pretty important advantage of merging is that it preserves semantic information completely lost by rebase, i.e. you can actually see when some feature development has started and ended. Merging also helps with bisecting, but this is probably out of scope for this overview. @b0rk future me: seriously? you changed 249 files in one commit?  Usually squash and merge: when bisect points at a squashed commit or a merge commit one gets much less information (so merge is somewhat better than squash, because you _might_ get a commit on the merged-in branch as a result). Rebase is much better, _as long as the project wants all commits on the main branch to actually build. If that's not the case, it's the worst (but then the notion of a commit as a version of the software is very degenerated anyway).  @b0rk panel 2 and 3 looks slightly confusing to me. The resulting squares (left most, coloured squares) seem to be rather different in panel 2. But then panel 3 emphasises that the resulting files are all the same. Still appreciate this explanation ! 🙏 @maxheadroom thanks! will think about how to make it clearer the reason for the discrepancy is that the **diffs** of the 3 commits are different but the **contents of the files** are the same @b0rk yeah, I figured that from reading the other panels. But visually I found it confusing at first. Maybe keep the content/icons inside the squares equal but the colours different?   @b0rk Mmmmm, flavoured suffering. Squash your PR branch to 1 commit, then Rebase is what we do.  @b0rk I always go to merge because why hide and destroy your past. A git doesn’t have to look nice it has to represent work history. @b0rk I love these explanations. There’s a real art to explaining something in the fewest words possible. Simplicity brings clarity.  > if you mess up the original commits are still in your branche's history git reflog to the rescue! No matter which method you choose, the original commits are not removed. Only the branch pointer moves (use tags)(remove them, when you're done or git gc won't be able to free up space) BTW fixup > squash. See also git commit --fixup and git rebase --autosquash.  @b0rk There's a fourth option though: The "student has their first merge conflict, panics and tries to sort it out themself instead of asking for help"-option. - Checked in conflict-markers: ☑️ @b0rk Perfect. What an elegant way to represent commit graphs. And thank you for articulating my dread of merge graphs A squash + rebase looks almost ideal to me. I'm going to do that more often. The negatives of squash + rebase look minor to me though. Is a 3000-line PR any better with the other options? |
@b0rk I burst out laughing on a call, unmuted, thanks to that third panel. >:(