The new forums will be named Coin Return (based on the most recent vote)! You can check on the status and timeline of the transition to the new forums here.
The Guiding Principles and New Rules document is now in effect.

[Programming] Page overflow to new thread

19596979899101»

Posts

  • EtheaEthea Registered User regular
    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.

    Like everything else KISS.

  • TelMarineTelMarine Registered User regular
    edited March 2023
    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
  • This content has been removed.

  • DrovekDrovek Registered User regular
    Orca wrote: »
    admanb wrote: »
    I don't think I've fucked up git in a way that couldn't be fixed with git reset --hard in years. wtf are you all doing?

    Seriously.

    git reset --hard or the reflog

    anything else are you like...doing blood magic on your repo or what?

    agv1ypacq9i3.png

    steam_sig.png( < . . .
  • SpoitSpoit *twitch twitch* Registered User regular
    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.

    steam_sig.png
  • hlprmnkyhlprmnky Registered User regular
    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.

    _
    Your Ad Here! Reasonable Rates!
  • This content has been removed.

  • PhyphorPhyphor Building Planet Busters Tasting FruitRegistered User regular
    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

  • This content has been removed.

  • hlprmnkyhlprmnky Registered User regular
    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!
  • admanbadmanb unionize your workplace Seattle, WARegistered User regular
    edited March 2023
    hlprmnky wrote: »
    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

    admanb on
  • This content has been removed.

  • zerzhulzerzhul Registered User, Moderator mod
    It is well past the time for a new thread - this one lasted almost a full four years!

This discussion has been closed.