4 ms·

`git merge` is for regular people who are measured by how much they can accomplish in a given timeframe. `git rebase` is for academics and startups where no on

`git merge` is for regular people who are measured by how much they can accomplish in a given timeframe. `git rebase` is for academics and startups where no one gives a fuck about anything and no one bats an eye if you waste a day or two on a rebase gone wrong. It's easy to undo a merge and a bit nasty if you already pushed the merge commit. But undoing a rebase? Oh god you're in for a lot of pain.

anonymoushn 2y ago
the old commits are still in your reflog, and if they belong to a branch that isn't only on your machine, you can nag a coworker if you don't know how to use that
tomjakubowski 2y ago
> But undoing a rebase? Oh god you're in for a lot of pain. It's actually pretty easy. You either make a checkpoint tag before you start the rebase, and reset to it if you notice something went wrong; or, if you forgot to make the checkpoint, check the reflog and find the commit you started from, and reset to that. Reflog has a flag which adds timestamps to every entry, which I find is helpful for this: git reflog --date=iso
alain_gilbert 2y ago
yeah, totally agree, it's so hard to type `git rebase --abort` (?)
- dullcrisp 2y ago
  Get out of here with your academic mumbo-jumbo
collingreen 2y ago
This doesn't match my experience and it is almost exactly opposite of my personal preference of rebased commits. I get that you want to be incendiary but I think this misses the point, perhaps on purpose. My good faith addition here: a major influence in this debate seems to me to be how a team views their repo. Merge heavy stuff makes great sense for a repo whose job is just to hold everything; essentially a big and powerful shared clipboard that has all the myriad work-in-progress. Almost like a "dumb" tool (and trust me when I say dumb with lots of love and respect - it isn't criticism it is about which direction coupling points). On the other hand, the rebase heavy approach makes more sense if you view the repo as a contextual knowledge store, holding an almost idealized version of the point in time, uncluttered by the reality of the path actually taken. To broadly generalize my experience, I've found the merge version is generally faster, has low overhead in the moment, and scales pretty well since it is nearly the lowest common denominator approach. Conversely, I've found the rebase version makes debugging and context switching faster and enables a leaner team to cover more ground because the repo has some context and documentation built in via its organization. Of course, doing either approach poorly will have negative consequences and being inconsistent in either approach is worse than consistently doing one or the other. I'm not trying to make an argument for which to choose but I am pushing back hard on rebase only being used by teams who are unprofessional and don't care about wasting their time.

anonymoushn 2y ago

the old commits are still in your reflog, and if they belong to a branch that isn't only on your machine, you can nag a coworker if you don't know how to use that

tomjakubowski 2y ago

> But undoing a rebase? Oh god you're in for a lot of pain. It's actually pretty easy. You either make a checkpoint tag before you start the rebase, and reset to it if you notice something went wrong; or, if you forgot to make the checkpoint, check the reflog and find the commit you started from, and reset to that. Reflog has a flag which adds timestamps to every entry, which I find is helpful for this: git reflog --date=iso

alain_gilbert 2y ago

yeah, totally agree, it's so hard to type `git rebase --abort` (?)

dullcrisp 2y ago
Get out of here with your academic mumbo-jumbo

collingreen 2y ago

This doesn't match my experience and it is almost exactly opposite of my personal preference of rebased commits. I get that you want to be incendiary but I think this misses the point, perhaps on purpose. My good faith addition here: a major influence in this debate seems to me to be how a team views their repo. Merge heavy stuff makes great sense for a repo whose job is just to hold everything; essentially a big and powerful shared clipboard that has all the myriad work-in-progress. Almost like a "dumb" tool (and trust me when I say dumb with lots of love and respect - it isn't criticism it is about which direction coupling points). On the other hand, the rebase heavy approach makes more sense if you view the repo as a contextual knowledge store, holding an almost idealized version of the point in time, uncluttered by the reality of the path actually taken. To broadly generalize my experience, I've found the merge version is generally faster, has low overhead in the moment, and scales pretty well since it is nearly the lowest common denominator approach. Conversely, I've found the rebase version makes debugging and context switching faster and enables a leaner team to cover more ground because the repo has some context and documentation built in via its organization. Of course, doing either approach poorly will have negative consequences and being inconsistent in either approach is worse than consistently doing one or the other. I'm not trying to make an argument for which to choose but I am pushing back hard on rebase only being used by teams who are unprofessional and don't care about wasting their time.