I gotta say I love when projects want you to rebase commits and generally smash everything in a branch down to a single commit ( love me a force push ).
Long as hell branches with multiple mainline merges ( or even worse spider merges into them ) just suck.
One weird thing that's happened to me a few times is that I'm in the middle of rebasing, I fixed any merge conflicts, try to continue, and it says "resolve all conflicts". I do "git status", it shows there is nothing to fix...
TelMarine on
3ds: 4983-4935-4575
0
Options
OrcaAlso known as EspressosaurusWrexRegistered Userregular
Rebasing is great for the case where you’re on a feature branch that has not yet left your machine, or at worst, that nobody else should have checked out from upstream for any reason. Right before you send up your PR to merge back to mainline, if you rebase to mainline then you won’t have a huge merge commit that is just “everything that happened to the mainline branch while I was working on this feature”. This eases the workload you are asking your PR reviewers to take on, and as such is a virtuous act.
The fact that rebase is a feature that only does what it’s supposed to during a specific phase of the lifecycle of a branch, and ruins things for everybody when used after that point, but is in no way documented as such nor constrained by any sort of controls to prevent you from making all your colleagues’ lives worse with a ton of force pushes and history changing, is peak git IMO.
I'm still not sold on rebasing. It just seems like a way to fuck up the repo for others.
If you want a clean commit history, make a pretty commit message when you squash everything into a single merge commit.
But @Spoit what if your commit is too big! Then the people who aren't going to read it anyway will complain it's too big for them to just eyeball briefly and say "looks fine".
Rebasing doesn't fuck up history in a way anyone should care about because
a) you shouldn't have long lived feature branches anyway so virtually nothing should be hanging off extant branches. Release branches can get cherry-picked to
b) you should really be using something like gerrit rather than force pushing and you can just run it in rebase/cherry-pick mode which does all of this automatically
c) there's little value in all the intermediate "quick fix" "forgot a file" commits that you lose in amend/rebase workflows
Okay so I've gotta love the blind optimism of "the database HA solution deploys, we just need to test it" and thus the ticket is marked as done.
This is a very simple test guys: delete one of the nodes and see if it keeps going. Since no one included "and it was tested" in that statement, I assume no one has, and as a result it absolutely is not "done" or even likely to not simply corrupt all the data.
That reminds me of the question I would always ask fellow local tech folks at meetups back when that was a thing that happened, upon hearing them say “…and now we’re migrating to a microservices architecture, it’s really exciting”, to wit:
“Oh cool! What does your architecture do when the database goes down?”
Every time I was hoping to meet someone who was doing cool things with distributed systems. Without fail, I got instead an uncomfortable silence and a new conversation partner.
_
Your Ad Here! Reasonable Rates!
+1
Options
admanbunionize your workplaceSeattle, WARegistered Userregular
That reminds me of the question I would always ask fellow local tech folks at meetups back when that was a thing that happened, upon hearing them say “…and now we’re migrating to a microservices architecture, it’s really exciting”, to wit:
“Oh cool! What does your architecture do when the database goes down?”
Every time I was hoping to meet someone who was doing cool things with distributed systems. Without fail, I got instead an uncomfortable silence and a new conversation partner.
The difference between "we're migrating to a microservices architecture because it solves a clear problem we have" and "we're migrating to a microservices architecture because our CEO/CTO/tech lead* read a white paper over the weekend."
*I know we prefer to roast non-technical management but never underestimate the ability of devs to be self-destructive
I swear I spend most of my time writing configuration systems and configuration parsers. Like the actual logic of whatever I'm doing is usually pretty straight forward, but I have to do a ton of work just getting the damn configuration expressed and validated.
Posts
Long as hell branches with multiple mainline merges ( or even worse spider merges into them ) just suck.
Like everything else KISS.
Seriously.
git reset --hard or the reflog
anything else are you like...doing blood magic on your repo or what?
If you want a clean commit history, make a pretty commit message when you squash everything into a single merge commit.
The fact that rebase is a feature that only does what it’s supposed to during a specific phase of the lifecycle of a branch, and ruins things for everybody when used after that point, but is in no way documented as such nor constrained by any sort of controls to prevent you from making all your colleagues’ lives worse with a ton of force pushes and history changing, is peak git IMO.
Your Ad Here! Reasonable Rates!
But @Spoit what if your commit is too big! Then the people who aren't going to read it anyway will complain it's too big for them to just eyeball briefly and say "looks fine".
a) you shouldn't have long lived feature branches anyway so virtually nothing should be hanging off extant branches. Release branches can get cherry-picked to
b) you should really be using something like gerrit rather than force pushing and you can just run it in rebase/cherry-pick mode which does all of this automatically
c) there's little value in all the intermediate "quick fix" "forgot a file" commits that you lose in amend/rebase workflows
This is a very simple test guys: delete one of the nodes and see if it keeps going. Since no one included "and it was tested" in that statement, I assume no one has, and as a result it absolutely is not "done" or even likely to not simply corrupt all the data.
“Oh cool! What does your architecture do when the database goes down?”
Every time I was hoping to meet someone who was doing cool things with distributed systems. Without fail, I got instead an uncomfortable silence and a new conversation partner.
Your Ad Here! Reasonable Rates!
The difference between "we're migrating to a microservices architecture because it solves a clear problem we have" and "we're migrating to a microservices architecture because our CEO/CTO/tech lead* read a white paper over the weekend."
*I know we prefer to roast non-technical management but never underestimate the ability of devs to be self-destructive