Anecdotally, I know a paying GCP customer that recently got quota blocked on the number of global static IPs they are allowed to create. We could not figure out how to contact someone to increase it, and nobody knew why the quota was set so low (4). We just kept running into automated systems that gave circular information on how to request an increase. We kept getting links to sign up for a free tier account.
Right. Unfortunately their right to request increases was removed. The exact wording: “Based on your service usage history you are not eligible for quota increase at this time” and then dead ends trying to reach someone.
They had billing accounts set up for all their projects. They were happy to hand over money but had no ability to.
I feel like you inadvertently confirmed the authors point. In your “complicated” example, in order to visually show the baseline after rebase you removed the earlier C3, C5, C7 and C9 commits. But the authors point is that merge commits just need better tooling that can make it clearer what the baseline is!
It's git that removed them, not me: rebase re-writes history, that's the whole point. They simply do not exist in the repo anymore after the rebase operation is committed.
In fact, following the same merge history as in the first example, I should have named the final ones C3''', C5''', and C9', since they get re-written several times. But, most of the time, this is entirely irrelevant to their history (especially when they don't even touch the same files as the changes being merged in).
Note that C7, C11 and C15 completely disappeared, since they are unnecessary. Instead of being extra commits clogging up the log, they are the history rewrite events that don't need to be consigned.
> Note that C7, C11 and C15 completely disappeared, since they are unnecessary. Instead of being extra commits clogging up the log, they are the history rewrite events that don't need to be consigned.
In my experience, there's no such thing as an "unnecessary" merge. Every merge commit encodes tree changes from the various merge strategies. Explicit merge commits keep those (mostly) separate from deliberate developer changes and make it easy to trace back a subtle merge bug or the wrong merge strategy.
Git's modern merge strategies today feel almost like magic and "never mismerge", so I don't blame anyone for never having had to trace through merge commit history for subtle mismerges today, and assuming in all cases the merge strategies "just do the right thing". But it still happens, those subtle, terrifying moments when the magic breaks down in subtle ways and the merge tree output isn't what you expect or need.
From my perspective, trusting rebases and squashes and cherry picks is putting sometimes way too much trust in git's various merge strategies. I do trust them, and rely on them for a lot. But I've also seen the dark sides of them: the need to find mismerge needles in large haystack branches, the gut wrenching low level micro-management of rerere caches to avoid similar mistakes in the future. Personally, I'd much rather have a million "unnecessary" merge commits than ever again need to mentally "bisect" a mismerge from a deliberate choice in some long gone developer's hand cherry picked and squashed commit where all the merge details are mixed in with all the other code changes and no clues where the dividing lines were.
Git can trivially rebase out those merges, but that begs the question why they were even done in the first place.
I can imagine that sometimes a feature depends on changes from develop after the start of the feature branch. This means that development started too early.
Cherry-picking my changes on to a new branch will hide that fact. Rebasing will conserve the authoring timestamp. I guess it depends on the specific situation what's best.
In a trunk-based development workflow, I'd have to merge asap and maybe hide things behind feature flags or compile-time switches to avoid such merges.
Things get even more interesting when the merges from develop affected files that were changed on the feature branch. You will likely get conflicts if you attempt to rebase them away.
Multiple features are normally developed in parallel. It's good practice to keep up to date with the latest develop/master to avoid surprises at later stages.
Rebasing your work onto the head of master before merging it in, versus cherry-picking the relevant changes from your branch onto the head of master, are perfectly identical in terms of end result - whichever workflow is easier for you will achieve the same thing.
And of course you can get conflicts if multiple people are developing over the same files - this will happen regardless of using merge, rebase, or cherry pick (or even patches over email). You fix the conflicts when merging / rebasing / cherry picking / accepting a patch.
> They simply do not exist in the repo anymore after the rebase operation is committed.
They do if yet another tag or branch still links to those commits. And in practice they'll stick around for a while anyway, accessible through the reflog.
Industrial IoT company | Canada | $60/day ($65 on weekends) for simply being on call, plus any alarm/issue after-hours I get paid my hourly-salary-equivalent with a minimum of 3hrs no matter what the issue is | on-call 26 weeks of each year.
I showed an interviewer a piece of something I built in a traditional page-per-view design, with some xmlhttprequest where appropriate, and a sprinkling of Vue where it added usability to some of the modal dialogs. Their only response was "why didn't you build it in React?".
I stopped interviewing for front-end work since then. The landscape changes frustratingly too often.
