• @lseif@sopuli.xyz
    link
    fedilink
    752 years ago

    if u ever get a tricky merge conflict, just git push --force. this automatically works out the right code to keep (your own)

  • katy ✨
    link
    fedilink
    382 years ago

    lemme rebase the main branch onto my branch.

    two minutes later

    1 merge conflict of 57 [abort] [continue]

    • @affiliate@lemmy.world
      link
      fedilink
      132 years ago

      this is easily fixed by copy pasting the files into a new directory and never opening git again out of fear

    • kamen
      link
      fedilink
      72 years ago

      One key thing that can help you wrap your head around rebasing is that branches get switched while you’re doing it; so, say you’re on branch feature and do git rebase master, for any merge conflict, whatever’s marked “current” will be on master and what’s “incoming” is from feature.

      There’s also git rerere that should in theory remember a resolution you do between two branches and reuse it every time after the first; I’ve rarely used it in practice; it would happen for long lived branches that don’t get merged.

  • stilgar [he/him]
    link
    fedilink
    English
    282 years ago

    Pro tip: If your code gets flogged by git, you can always get revenge with git reflog 😉

  • @lily33@lemm.ee
    link
    fedilink
    252 years ago

    Learning git is very easy. For example, to do it on Debain, one simply needs to run, sudo apt install lazygit

    • Kata1yst
      link
      fedilink
      242 years ago

      LazyGit may actually be black magic from Satan to tempt programmers into sin. And to that I say: ‘where is a goat I can sacrifice to my dark lord?’

    • Bipta
      link
      fedilink
      32 years ago

      Wow this looks great. Amend an old commit dealing with a rebase? Sign me up!

      • @zalgotext@sh.itjust.works
        link
        fedilink
        5
        edit-2
        2 years ago

        git rebase -i origin/main (or whatever branch you’re rebasing on), then read the instructions that come up in the editor window

        • corytheboyd
          link
          fedilink
          10
          edit-2
          2 years ago

          Read… instructions? I love teaching people that git very often prints out what you should do next.

          git: “to continue, resolve conflicts, add files, and run rebase —continue”
          dev: …time to search stack overflow

          All that said… just use lazygit. It does help to know CLI git first to put things in context, but if you do, no need to punish yourself every day by not using a UI.

    • @jcg@halubilo.social
      link
      fedilink
      1
      edit-2
      2 years ago

      I’d still probably prefer the usual CLI for setup, commits, pushes etc. but this looks like a godsend for any branching/rebasing operations!

      • @lily33@lemm.ee
        link
        fedilink
        1
        edit-2
        2 years ago

        The ease with which I can only commit separate hunks with lazygit has ensured I use it for commits, too. And once I’ve opened it to do the commit, I may as well also press P.

        • Alex
          link
          fedilink
          12 years ago

          Is this what people who haven’t been introduced to #magit use?

          • @lily33@lemm.ee
            link
            fedilink
            12 years ago

            Never tried magit, but it doesn’t matter. It couldn’t possibly be good enough to be worth using an inferior editor.

  • @roastpotatothief@lemmy.ml
    link
    fedilink
    21
    edit-2
    2 years ago

    Git is a great invention but it has a few design flaws. There are too many ways to confuse it or break it, using commands that look correct, or just forgetting something. I ended up writing simple wrapper script codebase to fix it. Since then no problems.

    • oce 🐆
      link
      fedilink
      162 years ago

      It was conceived for experts so the new user experience is shit and the UI is not intuitive. But it has become such a widespread standard that it is very hard to completely overhaul the UI.

      • @sheogorath@lemmy.world
        link
        fedilink
        92 years ago

        TBH compared to the old versioning system people used to use like SVN and Mercurial. Git is a godsend. Just taking your time in learning and not using a GUI client works wonders in learning how it works. Especially when all the GUI clients are basically a collection of commands being executed so if you fuck things up on CLI you know what happened vs using GUI.

      • @roastpotatothief@lemmy.ml
        link
        fedilink
        32 years ago

        Yes you couldn’t change something so widely used. Look what happened with python 3.

        Fortunately there’s already a tradition among Git users of building a UI on top of the git UI. My project is just a slightly better version of those. It lays a simple sensible interface on top of the chaotic Git interface.

      • Pxtl
        link
        fedilink
        English
        32 years ago

        Even for experts the user experience is shit. Too much has to be done manually when the default should be automatic, like fetching before pull, recursing when working with repos that use submodules, allowing mismatched casing on case insensitive filesystems, etc.

        • oce 🐆
          link
          fedilink
          22 years ago

          Submodule commands are such mess, which is sad because it is a great feature.

    • @Shhalahr@beehaw.org
      link
      fedilink
      12 years ago

      Yeah. It’s got no abstraction between the UI and the implementation. You just want to manage code versions, but to use Git, you need to learn how to manage history graphs.

  • @erogenouswarzone@lemmy.ml
    link
    fedilink
    English
    14
    edit-2
    2 years ago

    Great meme, and I’m sure op knows this, but for anyone else who is curious…

    007 in theory means:

    • 00: you have already committed your code to your local code base
    • 7: When you try to merge your code with everyone else’s there are 7 files that others have worked on since you last refreshed your local code base.

    To resolve this, you need to go file by file and compare your changes with the changes on the remote code. You need to keep the changes others have made and incorporate your own.

    You can use git diff file_name to see the differences.

    If you have made small changes, it’s easier to pull and force an overwrite of your local code and make changes again.

    However multiple people working on the same files is usually a sign of organizational issues with management. Ie, typically you don’t want multiple people working on the same files at the same time, to avoid stuff like this.

    If you’re not sure, ask someone that knows what they’re doing before you follow any advice on Lemmy.

      • @jjjalljs@ttrpg.network
        link
        fedilink
        42 years ago

        If I get a big conflict and I know my change is trivial, I feel perfectly okay doing git fetch git reset --hard whatever and then reapplying my simple change as a new commit. Sort of a bootleg rebate.

      • @erogenouswarzone@lemmy.ml
        link
        fedilink
        English
        22 years ago

        I hear what you’re saying.

        First, I hard disagree with you. Overwriting my local version of code is a parachute - not an ideal landing, but better than merging by hand.

        Also, my comment was not an attempt to teach everything about git, just to explain what is happening in simple terms, since git requires a lot of experience to understand what those messages mean.

      • @zalgotext@sh.itjust.works
        link
        fedilink
        12 years ago

        If you use a squash workflow, you’re going to be force pushing a ton.

        Never force git to do anything. If you’re forcing something you’re doing it wrong.

        This is bad advice. Better advice would be “know and understand your tool, and know the consequences of your actions”.

      • @lightnegative@lemmy.world
        link
        fedilink
        132 years ago

        Do it enough times and it stops being scary.

        Using a tool like VSCode to perform the actual merges on individual files also helps because it shows what “yours” and “theirs” changes are from a user perspective, not a git perspective

        • @boomzilla@programming.dev
          link
          fedilink
          22 years ago

          The 3-way merge editor in VSCode is a fantastic tool. Really helps in visualizing what comes from where and preventing merge accidents.

      • @buzziebee@lemmy.world
        link
        fedilink
        22 years ago

        It’s doable once you know what you’re doing. I can do it all via the cli, but I personally use gitkraken most of the time and it’s just so much easier and more ergonomic.

        I also see a lot of the Devs who insist they know what they’re doing create horrible messes of their branches super easily via the commit tree. People should just use whatever works best for them to get the job done.

    • oce 🐆
      link
      fedilink
      13
      edit-2
      2 years ago

      If it was dead simple you wouldn’t need to learn 10 new concepts and google commands regularly even after using it for a couple of years. You probably forgot how you struggled at first. I have taught it multiple times and I see how beginners struggle.

    • @sajran@lemmy.ml
      link
      fedilink
      English
      42 years ago

      I would actually say it’s VERY complicated but in daily work you probably need like 5 commands and those aren’t hard at all.