• merthyr1831@lemmy.world
    link
    fedilink
    arrow-up
    0
    ·
    edit-2
    7 months ago

    Heres my based af workflow:

    git checkout -b feature-branch

    rebase on top of dev whilst working locally

    git rebase origin/dev-branch && git push -f


    if i need to fix conflicts with dev-branch during a PR

    git merge origin/dev

    • Nate Cox@programming.dev
      link
      fedilink
      English
      arrow-up
      0
      ·
      7 months ago

      I remember learning about how to use this back in the day and what a game changer it was for my workflow.

      Today I like to do all of the commits as I’m working. Maybe dozens or more as I chug along, marking off waypoints rather than logging actual changes. When I’m done a quick interactive rebase cleans up the history to meaningful commits quite nicely.

      The fun part is that I will work with people sometimes who both swear that “rewriting history” is evil and should never be done, but also tell me how useful my commit logs are and want to know how I take such good notes as I go.

      • sping@lemmy.sdf.org
        link
        fedilink
        English
        arrow-up
        0
        ·
        edit-2
        7 months ago

        Even better, master creating fixup and squash commits and maintain logical commits as you work with git rebase -i --autosquash

      • magic_lobster_party@kbin.run
        link
        fedilink
        arrow-up
        0
        ·
        7 months ago

        At my company we just use a squash policy in gitlab. Every merge request becomes a single commit to the main branch. Super easy to read the commit log because all commits are descriptive instead of a bunch of “fix MR comments” or “fix pipeline errors”.

        Another advice: git reset [commit-id] followed with a git commit -a is a quick way to squash all your commits.

        • bort@sopuli.xyz
          link
          fedilink
          arrow-up
          0
          ·
          7 months ago

          Another advice …quick way to squash all your commits

          in your IDE select the commits you want to squash. Then rightclick. Then “squash”. All done.

            • bort@sopuli.xyz
              link
              fedilink
              arrow-up
              0
              ·
              7 months ago

              I use like 3 of the git-feature from intellij (out of 100 or so). But these 3 features save me a lot of time.

              (the other 2 being the 3-way-merge-view and the commit-view where I can select changes for staging)

      • swordsmanluke@programming.dev
        link
        fedilink
        arrow-up
        0
        ·
        7 months ago

        Argh. I hate that argument.

        Yes - “Rewriting history” is a Bad Thing - but o argue that’s only on ‘main’ (or other shared branches). You should (IMHO) absolutely rewrite your local history pre-push for exactly the reasons you state.

        If you rewrite main’s history and force your changes everybody else is gonna have conflicts. Also - history is important for certain debugging and investigation. Don’t be that guy.

        Before you push though… rebasing your work to be easily digestible and have a single(ish) focus per commit is so helpful.

        • review is easier since concerns aren’t mixed
        • If a commit needs to be reverted it limits the collateral damage
        • history is easier to follow because the commits tell a story

        I use a stacked commit tool to help automate rebasing on upstream commits, but you can do it all with git pretty easily.

        Anyway. Good on you; Keep the faith; etc etc. :)

        • thesmokingman@programming.dev
          link
          fedilink
          arrow-up
          0
          ·
          7 months ago

          The only other time rewriting history might be bad is when you’re working on a shared branch, which is the point of not rewriting main. If you are working solo on a branch, its history is only what you merge into main so it doesn’t fucking matter at all. If you’re not working solo, maybe you need to adopt a similar process or look at how you’re not working solo. The only time I touch another dev’s branch is at the PR stage and only for quick corrections or missing knowledge so it doesn’t matter if they rebased before or honestly rebase after before the final merge.

          • FiniteBanjo@lemmy.today
            link
            fedilink
            arrow-up
            0
            ·
            edit-2
            7 months ago

            Platforms of the same nature like Mastodon.social ? Because no.

            Actually, internal reports seem to indicate Twitter under Musk complies with much more takedown requests than it did previously, numbers seem to range from 80% to 98%, including requests from countries like China, Ethiopia, Turkey, etc. When people mention censorship by big tech the top three names are Twitter, Facebook, and Google. The only time I know of that twitter fought censorship was when India wanted them to takedown news about farmers’ protests, and Twitter lost in court, probably owing largely to the fact that he cut staff by 80% and ran the company’s finance into the ground by endorsing hate speech.

            • Zuberi 👀@lemmy.dbzer0.com
              link
              fedilink
              arrow-up
              0
              ·
              7 months ago

              No, I did not include mastodon in the “other platforms” because 99% of the normies aren’t on decentralized platforms anyway.

              Very small pond we’re discussing, as sad as that is.

              All I did was answer why THEY think Twitter is worth using. I personally don’t use Twitter, nor do I disagree w/ your take on censorship.

    • TheHarpyEagle@lemmy.world
      link
      fedilink
      arrow-up
      0
      ·
      7 months ago

      I tried it for a moment, made games stutter like hell, switched back. I know I need to go in and figure it out at some point, but it’s hard to muster the energy when X, for the most part, works fine.

      From what I’ve seen, it probably has to do with my Nvidia GPU.

      • 30p87@feddit.de
        link
        fedilink
        arrow-up
        0
        ·
        7 months ago

        I’m currently at the point where I blame everything that works on my Laptop but not on my PC on Nvidia, because that’s literally the biggest difference between those two. Like currently my getty isn’t displaying properly, which is surely NVidias fault.

    • 13@kbin.run
      link
      fedilink
      arrow-up
      0
      ·
      7 months ago

      I use X because Cinnamon on Wayland has no option to change the keyboard layout

      • merthyr1831@lemmy.world
        link
        fedilink
        arrow-up
        0
        ·
        7 months ago

        I tried their experimental Wayland session and it’s still super buggy on high refresh rate/high DPI screens (loads of graphical errors and artifacts) so still a ways to go imo

    • T156@lemmy.world
      link
      fedilink
      English
      arrow-up
      0
      ·
      7 months ago

      Wayland really doesn’t like RDP/remote access, so X is the only way to go if you want that to work properly.

      • AArun@programming.dev
        link
        fedilink
        arrow-up
        0
        ·
        7 months ago

        I actually never had an issue on my wayland system. I used remmina for rdp but never had an issue.

    • Muad'Dibber@lemmygrad.ml
      link
      fedilink
      arrow-up
      0
      ·
      7 months ago

      You try to pull someone’s changes, but whoops, they used rebase and rewrote history! Delete the branch and start over.

      • thesmokingman@programming.dev
        link
        fedilink
        arrow-up
        0
        ·
        7 months ago

        No you just do a rebase to bring it in. Assuming you’re making atomic commits you shouldn’t have a ton of merge conflicts. If you have to do this a lot, your branch scope is really bad and the problem isn’t in how you’re using got, it’s in how you’re slicing work.

        • Muad'Dibber@lemmygrad.ml
          link
          fedilink
          arrow-up
          0
          ·
          7 months ago

          If you try to pull someone else’s rebased / history rewritten branch, your git will tell you that it’s rejected. You can completely avoid this by merging instead of rewriting history.

      • expr@programming.dev
        link
        fedilink
        arrow-up
        0
        ·
        edit-2
        7 months ago

        2 things:

        1. You don’t pull rebased work pretty much ever. Rebasing is for feature branches by a single author to craft a high quality history, generally. It’s much, much better than littering your branch with merge commits from upstream.
        2. If for some reason you do need to pull rebased changes, you simply do git pull --rebase. Works without issue.
  • passepartout@feddit.de
    link
    fedilink
    arrow-up
    0
    ·
    7 months ago

    I like the idea of it and there were times i used it correctly, but most of the time i do it wrong i guess.

    • andrew@lemmy.stuart.fun
      link
      fedilink
      English
      arrow-up
      0
      ·
      7 months ago

      Merge takes two commits and smooshes them together at their current state. Rebase takes a whole branch and moves it, as if you started working on it from a more recent base commit.

        • Atemu@lemmy.ml
          link
          fedilink
          arrow-up
          0
          ·
          7 months ago

          The only difference between a *rebase-merge and a rebase is whether main is reset to it or not. If you kept the main branch label on D and added a feature branch label on G’, that would be what @andrew@lemmy.stuart.fun meant.

        • bort@sopuli.xyz
          link
          fedilink
          arrow-up
          0
          ·
          7 months ago

          why would rebasing a feature branch change main?

          the image does not update the feature branch. It merges the featurebranch into main with a regular old merge-commit on the main branch.

        • andrew@lemmy.stuart.fun
          link
          fedilink
          English
          arrow-up
          0
          ·
          7 months ago

          Yeah, the image (not mine, but the best I found quickly) kinda shows a rebase+merge as the third image. As the other commenter mentioned, the new commit in the second image is the merge commit that would include any conflict resolutions.

      • Elise@beehaw.org
        link
        fedilink
        arrow-up
        0
        ·
        7 months ago

        I’m relatively new to git and rebase looks like a mess to me? Like it appears to be making duplicate commits and destroys the proper history?

        If you use rebase to get a more readable history, isn’t the issue the tool you use to view the history?

        I guess I have to try it out a few times to get it.

        • Ephera@lemmy.ml
          link
          fedilink
          arrow-up
          0
          ·
          7 months ago

          What you probably mean by duplicate commits is that it assigns new commit IDs to commits that have been rebased. If you had already pushed those commits, then git status will tell you that the remote branch and your local branch have diverged by as many commits as you rebased.

          Well, and what is the “proper history”? If your answer is “chronological”, then why so?
          For the rare times that it matters when exactly a commit was created, they’ve got a timestamp. But otherwise, the “proper history” is whatever you make the proper history. What matters is that the commits can be applied one after another, which a rebase ensures.

          When you’re working on a branch and you continuously rebase on the branch you want to eventually merge to, then the merged history will look as if you had checked out the target branch and just made your commits really quickly without anyone else committing anything in between.
          And whether you’ve done your commits really quickly or over the course of weeks, that really shouldn’t matter.

          What is really cool about (supposedly) making commits really quickly is that your history becomes linear and it tells a comprehensible story. It won’t be all kinds of unrelated changes mixed randomly chronologically, but rather related commits following one another.
          And of course, you also lose the merge-commits, which convey no valuable information of their own.

          • Atemu@lemmy.ml
            link
            fedilink
            arrow-up
            0
            ·
            7 months ago

            you also lose the merge-commits, which convey no valuable information of their own.

            In a feature branch workflow, I do not agree. The merge commit denotes the end of a feature branch. Without it, you lose all notion of what was and wasn’t part of the same feature branch.

            • someonesmall@lemmy.ml
              link
              fedilink
              arrow-up
              0
              ·
              7 months ago

              Agreed, you also lose the info about the resolved merge conflicts during the merge (which have been crucial a few times to me).

      • Crow@lemmy.blahaj.zone
        link
        fedilink
        arrow-up
        0
        ·
        7 months ago

        That’s pretty cool, might actually do that. Tho, we currently don’t use the history as much anyways, we’re just having a couple of small student projects with the biggest group being 6 people. I guess it’s more useful if you’re actually making a real product in a huge project that has a large team behind it

        • ScreaminOctopus@sh.itjust.works
          link
          fedilink
          English
          arrow-up
          0
          ·
          7 months ago

          I wouldn’t recommend it. The Git documentation itself doesn’t recommend rebase for more than moving a few unpushed commits to the front of a branch you are updating. Using it by default instead of merge requires you to use --force-push as part of your workflow which can lead to confusing situations when multiple developers end up commiting to the same branch, and at worst can lead to catastrophic data loss. The only benefit is a cleaner history graph, which is rarely used anyway, and you can always make the history graph easier to read with a gui without incuring any of the problems of rebase.

          • surge_1@lemmy.world
            link
            fedilink
            arrow-up
            0
            ·
            7 months ago

            Bad take IMO,

            At 10+ YOE, I use rebase almost exclusively. Branch from main, rebase to clean up commit history before putting up a PR. If commits are curated properly you don’t run into conflicts very often. Branches really shouldn’t be shared too often anyway, and the ones that are should be write protected.

            Catastrophic data loss isn’t really possible either with git since it’s all preserved and you can git reflog even if you mess up.

            The meme is right. Git good

            • AggressivelyPassive@feddit.de
              link
              fedilink
              arrow-up
              0
              ·
              7 months ago

              Years of experience don’t really matter here, that’s just call to authority, in this case yourself. You might as well be the worst git user ever after 20 years of usage, or the best after 2. We don’t know that.

              Anyway, what you’re saying basically requires a perfect world to be true. Feature branch flow is perfectly fine, but you do end up with merge conflicts constantly, unless you have cordoned off areas of the repo for certain users. Two people working on unrelated features, both change a signature of some helper/util method, merge conflict. Nothing serious, can be fixed in a minute, and rebasing or merging won’t help for either.

              Merge is perfectly fine. And arguing about which strategy to use is one of those autistic debates we as an industry seemingly love to have. It doesn’t matter, but you’ll find people screaming at each other about it. See Emacs vs. Vi. Same crap.

              • surge_1@lemmy.world
                link
                fedilink
                arrow-up
                0
                ·
                7 months ago

                Merge is fine, but not knowing both rebase and merge is dumb. And I guess I’ve been in a perfect world this whole time in huge technical orgs lol.

            • Croquette@sh.itjust.works
              link
              fedilink
              arrow-up
              0
              ·
              7 months ago

              When rebasing, it applies the changes without the commit history?

              Does that mean that when you fast forward your main/dev branch and commit, you then add a single commit that encompasses every changes that were rebase?

              • expr@programming.dev
                link
                fedilink
                arrow-up
                0
                ·
                edit-2
                7 months ago

                No, there are no fast-forwards with rebasing. A rebase will take take the diff of each commit on your feature branch that has diverged from master and apply those each in turn, creating new commits for each one. The end result is that you have a linear history as though you had branched from master and made your commits just now.

                If you had branched like this:

                A -> B -> C (master)
                   \
                     \ -> D (feature)
                

                It would like this after merging master into your feature branch:

                A -> B -> C (master) ->   E (feature)
                  \                                    /
                    \ -> D -------------------> /
                

                And it would like this if you instead rebased your feature branch onto master:

                A -> B -> C (master) -> D' (feature)
                

                This is why it’s called a “rebase”: the current state of master becomes the starting point or “base” for all of your subsequent commits. Assuming no conflicts, the diff between A and D is the same as the diff between A and D'.

          • expr@programming.dev
            link
            fedilink
            arrow-up
            0
            ·
            7 months ago

            This a really bad take and fundamentally misunderstands rebasing.

            First off, developers should never be committing to the same branch. Each developer maintains their own branch. Work that needs to be tested together before merging to master belongs on a dedicated integration branch that each developer merges their respective features branches into. This is pretty standard stuff.

            You don’t use rebasing on shared branches, and no one arguing for rebasing is suggesting you do that. The only exception might be perhaps a dedicated release manager preparing a release or a merge of a long-running shared branch. But that is the kind of thing that’s communicated and coordinated.

            Rebasing is for a single developer working on a feature branch to produce a clean history of their own changes. Rebasing in this fashion doesn’t touch any commits other than the author’s. The purpose is to craft a high quality history that walks a reader through a proposed sequence of logical, coherent changes.

            Contrary to your claim, a clean history is incredibly valuable. There’s many tools in git that benefit significantly from clean, well-organizes commits. git bisect, git cherry-pick… Pretty much any command that wants to pluck commits from history for some reason. Or even stuff like git log -L or git blame are far more useful when the commit referenced is not some giant amalgamation of changes from all over the place.

            When working on a feature branch, if you’re merging upstream into your branch, you’re littering your history with pointless, noisy commits and making your MR harder to review, in addition to making your project’s history harder to understand and navigate.

        • RecluseRamble@lemmy.dbzer0.com
          link
          fedilink
          arrow-up
          0
          ·
          edit-2
          7 months ago

          Just remember to not combine it with force push or you’re in for some chaos (rewriting history team members have already fetched is a big no-no).

            • zalgotext@sh.itjust.works
              link
              fedilink
              arrow-up
              0
              ·
              7 months ago

              Force pushes are perfectly safe if you’re working on your own branch, and even if you’re sharing a branch, you can still force push to it as long as you inform and coordinate with whoever else is working on that branch.

            • expr@programming.dev
              link
              fedilink
              arrow-up
              0
              ·
              7 months ago

              Or, you know, on your own feature branch to clean up your own commits. It’s much, much better than constantly littering your Branch’s history with useless merge commits from upstream, and it lets you craft a high-quality, logical commit history.

              • Transtronaut@lemmy.blahaj.zone
                link
                fedilink
                arrow-up
                0
                ·
                7 months ago

                You can do all that without force push. Just make a new branch and do the cleanup before the first push there. Allowing force push just invites disaster from junior developers who don’t know what they’re doing. If you want to clean up after them, that’s your business, I guess.

              • RecluseRamble@lemmy.dbzer0.com
                link
                fedilink
                arrow-up
                0
                ·
                7 months ago

                Of course it has its uses. I didn’t mention them because the guy just learned about rebase - it’s unlikely to be applied flawlessly from the start.

                • expr@programming.dev
                  link
                  fedilink
                  arrow-up
                  0
                  ·
                  7 months ago

                  I was replying to the other comment, not yours. Though there’s not really a way of using rebasing without force pushing unless it’s a no-op.

                  Rebasing is really not a big deal. It’s not actually hard to go back to where you were, especially if you’re using git rebase --interactive. For whatever reason people don’t seem to get that commits aren’t actually ever lost and it’s not that hard to point HEAD back to some previous commit.

    • BlackPenguins@lemmy.world
      link
      fedilink
      arrow-up
      0
      ·
      edit-2
      7 months ago

      Merge is taking all the code from the master branch and combining it with the task branch, resulting in a commit for just the merge itself.

      Rebase is “re-basing” where your task branch was created from off the master branch. It essentially takes all the commits from master that happened since you branched, REWRITES THE HISTORY of your task branch by inserting those master branch commits before all your existing commits, and effectively makes your task branch look like it was branched yesterday instead of like 4 weeks ago. You changed where your task branch originated on the master. You moved its base.

      Atlassian does a fantastic writeup on this.

        • BlackPenguins@lemmy.world
          link
          fedilink
          arrow-up
          0
          ·
          edit-2
          7 months ago

          Kind of. Both merge and rebase result in the branches “synced up” but they do it in different ways.

          Merge is making a batter for cookies, having a bowl for dry ingredients (task branch) and a bowl for wet ingredients, (master branch) making them separately and then just dumping the dry bowl into the wet bowl (merge).

          Rebase is taking a time machine back to before you started mixing the wet ingredients, mix all the dry ingredients first then add the wet ones on top of that in the same bowl.

          It’s really hard to create an analogy for this.

      • Crow@lemmy.blahaj.zone
        link
        fedilink
        arrow-up
        0
        ·
        edit-2
        7 months ago

        So, with a merge you basically shuffle in the changes from both branches, but a rebase takes only the changes from one branch and puts it over the other? Edit: no. Read wrong. I should probably watch a vid about it or something

  • JoYo@lemmy.ml
    link
    fedilink
    arrow-up
    0
    ·
    7 months ago

    Anyone mind explaining to me how git rebase is worth the effort?

    git merge has it’s own issues but I just don’t see any benefit to rebase over it.

    • Jesus_666@feddit.de
      link
      fedilink
      arrow-up
      0
      ·
      edit-2
      7 months ago

      I use interactive rebases to clean up the history of messy branches so they can be reviewed commit by commit, with each commit representing one logical unit or type of change.

      Mind you, getting those wrong is a quick way to making commits disappear into nothingness. Still useful if you’re careful. (Or you can just create a second temporary branch you can fall back onto of you need up your first once.)

      • bamboo@lemmy.blahaj.zone
        link
        fedilink
        English
        arrow-up
        0
        ·
        7 months ago

        This 100%. I hate getting added to a PR for review with testing commits in the history, and I’m expected to clean those up before merging into main.

        • Zangoose@lemmy.one
          link
          fedilink
          arrow-up
          0
          ·
          7 months ago

          I feel like squash and merge on GitHub/GitLab is nicer for that anyway though, it makes the main branch so much cleaner automatically

    • Aux@lemmy.world
      link
      fedilink
      arrow-up
      0
      ·
      7 months ago

      Well, rebase allows you to resolve the same conflict ten times in a row instead of doing it once. How cool is that?

    • bitcrafter@programming.dev
      link
      fedilink
      arrow-up
      0
      ·
      7 months ago

      The way I structure my commits, it is usually (but not always) easier and more reliable for me to replay my commits one at a time on top of the main branch and see how each relatively small change needs to be adapted in isolation–running the full test suite at each step to verify that my changes were correct–than to be presented with a slew of changes all at once that result from marrying all of my changes with all of the changes made to the main branch at once. So I generally start by attempting a rebase and fall back to a merge if that ends up creating more problems than it solves.

    • Muad'Dibber@lemmygrad.ml
      link
      fedilink
      arrow-up
      0
      ·
      7 months ago

      Only before you collaborate with anyone else. After that, don’t ever use rebase, or they’ll get an error, and will have to overwrite their local history with the one you’ve rewritten.

  • Cyborganism@lemmy.ca
    link
    fedilink
    arrow-up
    0
    ·
    7 months ago

    I prefer to rebase as well. But when you’re working with a team of amateurs who don’t know how to use a VCS properly and never update their branc with the parent branch, you end up with lots of conflicts.

    I find that for managing conflicts, rebase is very difficult as you have to resolve conflicts for every commit. You can either use rerere to repeat the conflict resolution automatically, or you can squash everything. But when you’re dealing with a team of Git-illeterate developers (which is VERY often the case) you can either spend the time to educate them and still risk having problems because they don’t give a shit, or you can just do a regular merge and go on with your life.

    Those are my two cents, speaking from experience.

    • TechNom (nobody)@programming.dev
      link
      fedilink
      English
      arrow-up
      0
      ·
      7 months ago

      I agree that merge is the easier strategy with amateurs. By amateurs I mean those who cannot be bothered to learn about rebase. But what you really lose there is a nice commit history. It’s good to have, even if your primary strategy is merging. And people tend to create horrendous commit histories when they don’t know how to edit them.

      • AggressivelyPassive@feddit.de
        link
        fedilink
        arrow-up
        0
        ·
        7 months ago

        Honestly, I’m pretty sure 99.9% of git users never really bother with the git history in any way that would be hindered by merging.

        Git has a ton of powerful features, but for most projects they don’t matter at all. You want a distributed consensus, that’s it. Bothering yourself with all those advanced features and trying to learn some esoteric commands is frankly just overhead. Yes, you can solve great problems with them, but these problems almost never occur, and if they do, using the stupid tools is faster overall.

        • TechNom (nobody)@programming.dev
          link
          fedilink
          English
          arrow-up
          0
          ·
          7 months ago

          Only users who don’t know rebasing and the advantages of a crafted history make statements like this. There are several projects that depend on clean commit history. You need it for conventional commit tools (like commitzen), pre-commit hook tools, git blame, git bisect, etc.

          • AggressivelyPassive@feddit.de
            link
            fedilink
            arrow-up
            0
            ·
            7 months ago

            Uuuh, am I no true Scotsman?

            Counter argument: why do you keep fucking up so bad you need these tools? Only users who are bad at programming need these. Makes about as much sense as your accusation.

            You keep iterating the same arguments as the rest here, and I still adhere to my statement above: hardly anybody needs those tools. I literally never used pre-commit hooks or bisect in any semi-professional context. And I don’t know a single project that uses them. And before you counter with another “well u stoopid then” comment: the projects I’ve been working on were with pretty reputable companies and handled literally billions of Euros every year. I can honestly say, that pretty much everyone living in Germany had his/her data pushed through code that I wrote.

            • TechNom (nobody)@programming.dev
              link
              fedilink
              English
              arrow-up
              0
              ·
              7 months ago

              Uuuh, am I no true Scotsman?

              That’s a terrible and disingenuous take. I’m saying that you won’t understand why it’s useful till you’ve used it. Spinning that as no true Scotsman fallacy is just indicative of that ignorance.

              You keep iterating the same arguments as the rest here, and I still adhere to my statement above: hardly anybody needs those tools.

              And you keep repeating that falsehood. Isn’t that the real no true Scotsman fallacy? How do you even pretend to know that nobody needs it? You can’t talk for everyone else. Those who use it find it useful in several other ways that I and others have explained. You can’t just judge it away from your position of ignorance.

        • Chamomile 🐑@furry.engineer
          link
          fedilink
          arrow-up
          0
          ·
          edit-2
          7 months ago

          @agressivelyPassive @technom That’s a self-fulfilling prophecy, IMO. Well-structured commit histories with clear descriptions can be a godsend for spelunking through old code and trying to work out why a change was made. That is the actual point, after all - the Linux kernel project, which is what git was originally built to manage, is fastidious about this. Most projects don’t need that level of hygiene, but they can still benefit from taking lessons from it.

          To that end, sure, git can be arcane at the best of times and a lot of the tools aren’t strictly necessary, but they’re very useful for managing that history.

          • AggressivelyPassive@feddit.de
            link
            fedilink
            arrow-up
            0
            ·
            7 months ago

            I’d still argue, that the overhead is not worth it most of the time.

            Linux is one of the largest single pieces of software in existence, of course it has different needs than the standard business crap the vast majority of us develop.

            To keep your analogy: not every room is an operating room, you might have some theoretical advantages from keeping your kitchen as clean as an OR, but it’s probably not worth the hassle.

            • zalgotext@sh.itjust.works
              link
              fedilink
              arrow-up
              0
              ·
              7 months ago

              To keep your analogy, most people’s git histories, when using a merge-based workflow, is the equivalent of never cleaning the kitchen, ever.

              • AggressivelyPassive@feddit.de
                link
                fedilink
                arrow-up
                0
                ·
                7 months ago

                No, it’s not. And you know that.

                Seriously, ask yourself, how often did the need arise to look into old commits and if it did, wasn’t the underlying issue caused by the processes around it? I’ve been in the industry for a few years now and I can literally count on one hand how often I had to actually look at commit history for more than maybe 10 commits back. And I spend maybe 10min per year on that on average, if at all.

                I honestly don’t see a use case that would justify the overhead. It’s always just “but what if X, then you’d save hours!” But X never happens or X is caused by a fucked up process somewhere else and git is just the hammer to nail down every problem.

                • zalgotext@sh.itjust.works
                  link
                  fedilink
                  arrow-up
                  0
                  ·
                  7 months ago

                  Seriously, ask yourself, how often did the need arise to look into old commits

                  Literally every single day. I have a git alias that prints out the commit graph for my repositories, and by looking at that I can instantly see what tasks my coworkers are working on, what their progress is, and what their work is based on. It’s way more useful than any stand-up meeting I’ve ever attended.

                  I’ve been in the industry for a few years now and I can literally count on one hand how often I had to actually look at commit history for more than maybe 10 commits back.

                  I’ve been in the industry for nearly 15 years, but I can say that the last 3 years have been my most productive, and I attribute a lot of that to the fact that I’m on a team that cares about git history, knows how to use it, and keeps it readable. Like other people have been saying, this is a self fulfilling prophecy - most people don’t care to keep their git history readable, so they’ve only ever seen unreadable git histories, and so they think git history is useless.

                  I honestly don’t see a use case that would justify the overhead.

                  What overhead? The learning curve on rebasing isn’t that much steeper than that of merging or just using git itself. Take an hour to read the git docs, watch a tutorial or two, and you’re good to go. Understand that people actually read your commit messages and take 15 extra seconds to make them actually useful. Take an extra minute before opening an MR to rebase your personal branches interactively and squash down the “fixed a typo” and “ran isort” commits into something that’s actually useful. In the long run this saves time by making your code more easily reviewable, and giving reviewers useful context around your changes.

                  It’s always just “but what if X, then you’d save hours!” But X never happens or X is caused by a fucked up process somewhere else and git is just the hammer to nail down every problem.

                  No, having a clean, readable git history literally saves my team hours. I haven’t had to manually write or edit a changelog in three years because we generate it automatically from our commit messages. I haven’t had to think about a version number in three years because they’re automatically calculated from our commit messages. Those are the types of things teams sink weeks into, time absolutely wasted spent arguing over whether this thing or that is a patch bump or a minor bump, and no one can say for sure without looking at diffs or spinning up multiple versions of the code and poking it manually, because the git log is a tangled mess of spaghetti with meatballs made of messages like “finally fixed the thing” and “please just work dammit”. My team can tell you those things instantly just by looking at the git log. Because we care about history, and we keep it clean and useable.

          • zalgotext@sh.itjust.works
            link
            fedilink
            arrow-up
            0
            ·
            7 months ago

            Yup, once you can use git with good hygiene, it opens up the door to add in other tools like commitizen and semantic-release, which completely automates things like version number bumps and changelog generation.

      • xigoi@lemmy.sdf.org
        link
        fedilink
        arrow-up
        0
        ·
        7 months ago

        Why would you want to edit your commit history? When I need to look at it for some reason, I want to see what actually happened, not a fictional story.

        • Atemu@lemmy.ml
          link
          fedilink
          arrow-up
          0
          ·
          7 months ago

          Because when debugging, you typically don’t care about the details of wip, some more stuff, Merge remote-tracking branch 'origin/master', almost working, Merge remote-tracking branch 'origin/master', fix some tests etc. and would rather follow logical steps being taken in order with descriptive messages such as component: refactor xyz in preparation for feature, component: add do_foo(), component: implement feature using do_foo() etc.

        • TechNom (nobody)@programming.dev
          link
          fedilink
          English
          arrow-up
          0
          ·
          7 months ago

          You can have both. I’ll get to that later. But first, let me explain why edited history is useful.

          Unedited histories are very chaotic and often contains errors, commits with partial features, abandoned code, reverted code, out-of-sequence code, etc. These are useful in preserving the actual progress of your own thought. But such histories are a nightmare to review. Commits should be complete (a single commit contains a full feature) and in proper order. If you’re a reviewer, you also wouldn’t want to waste time reviewing someone else’s mistakes, experiments, reverted code, etc. Self-complete commits also have another advantage - users can choose to omit an entire feature by omitting a commit.

          Now the part about having both - the unedited and carefully crafted history. Rebasing doesn’t erase the original branch. You can preserve it by creating a new branch. Or, you can recover it from reflog. I use it to preserve the original development history. Then I submit the edited/crafted history/branch upstream.

    • magic_lobster_party@kbin.run
      link
      fedilink
      arrow-up
      0
      ·
      7 months ago

      How others are keeping their branches up to date is their problem. If you use Gitlab you can set up squash policy for merge requests. All the abomination they’ve caused in their branch will turn into one nice commit to the main branch.

      • trxxruraxvr@lemmy.world
        link
        fedilink
        arrow-up
        0
        ·
        7 months ago

        In a small team at a small company it becomes my problem pretty quickly, since I’m the only one that actually has some clue about what git does.

        • Cyborganism@lemmy.ca
          link
          fedilink
          arrow-up
          0
          ·
          7 months ago

          This. When they get any sort of conflicts in their pull request, it becomes MY problem because they don’t know what to do.

        • zalgotext@sh.itjust.works
          link
          fedilink
          arrow-up
          0
          ·
          7 months ago

          Heaven forbid my teammates read any documentation or make any attempt to understand the tooling necessary to do their job.

          That being said, I taught my dumbass git-illiterate team members a rebase workflow, with the help of the git UI in Pycharm. Haven’t had any issues with merge conflicts yet, but that might just be because they’re too scared to ask me for help any more

      • expr@programming.dev
        link
        fedilink
        arrow-up
        0
        ·
        7 months ago

        I don’t want squashed commits. It makes git tools worse (git bisect, git cherry-pick, etc.) and I work very hard to craft a meaningful set of commits for my work and I don’t want to throw all of that away.

        But yeah, I don’t actually give a shit what they are doing on their branches. I regularly rebase onto master anyway.

  • katy ✨@lemmy.blahaj.zone
    link
    fedilink
    arrow-up
    0
    ·
    7 months ago

    i like to create ten different checkouts of main, rebase them all slightly differently and then no fast forward merge them all back into each other

  • Zagorath@aussie.zone
    link
    fedilink
    English
    arrow-up
    0
    ·
    7 months ago

    Okay this is the second time I’ve seen Sydney Sweeney referenced in a meme in less than half a day. I had never heard of her before. Who is she, and why is she suddenly attracting so much meme attention?

  • Margot Robbie@lemm.ee
    link
    fedilink
    arrow-up
    0
    ·
    7 months ago

    I think this is a fake quote that somebody made up for an Internet comedy bit, since it seems unlikely for Hollywood actress Sydney Sweeney to have such uncharacteristically strong opinion on software version control, of all things.

    Because she of all people would know that there isn’t anything wrong with using git merge, and it ultimately comes down to personal preference to what you are used to.

      • ManniSturgis@lemmy.zip
        link
        fedilink
        arrow-up
        0
        ·
        7 months ago

        Wait a second, there wasn’t even any social media sites back when Benjamin Franklin lived. Did he write that in his newsletter or something?

    • Jax@sh.itjust.works
      link
      fedilink
      arrow-up
      0
      ·
      7 months ago

      But esteemed Academy Award nominated character actress and film director, Margot Robbie, if it’s unlikely that Hollywood actress Sydney Sweeney said this… wouldn’t it be just as unlikely that Margot Robbie would be here? Adding her own comment?

      … are you projecting? Is there something you want to tell us esteemed Academy Award nominated character actress and film director Margot Robbie?

    • Artyom@lemm.ee
      link
      fedilink
      arrow-up
      0
      ·
      7 months ago

      Margot Robbie, I was about to agree with you and thought that was a very reasonable take, until you tried to argue that git merge is better than git rebase, then I simply had to disregard the whole thing.

    • hactar42@lemmy.world
      link
      fedilink
      arrow-up
      0
      ·
      7 months ago

      I think this is a fake quote that somebody made up for an Internet comedy bit

      You can tell by the pixels