• lseif@sopuli.xyz
    link
    fedilink
    arrow-up
    75
    arrow-down
    4
    ·
    1 year ago

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

    • affiliate@lemmy.world
      link
      fedilink
      arrow-up
      13
      ·
      1 year ago

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

    • kamen@lemmy.world
      link
      fedilink
      arrow-up
      7
      ·
      1 year 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.

  • lily33@lemm.ee
    link
    fedilink
    arrow-up
    26
    ·
    1 year ago

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

    • Kata1yst@kbin.social
      link
      fedilink
      arrow-up
      25
      ·
      1 year 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?’

      • zalgotext@sh.itjust.works
        link
        fedilink
        arrow-up
        5
        ·
        edit-2
        1 year 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@kbin.social
          link
          fedilink
          arrow-up
          10
          ·
          edit-2
          1 year 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
      arrow-up
      1
      ·
      edit-2
      1 year 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
        arrow-up
        1
        ·
        edit-2
        1 year 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.

          • lily33@lemm.ee
            link
            fedilink
            arrow-up
            1
            ·
            1 year 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
    arrow-up
    22
    arrow-down
    1
    ·
    edit-2
    1 year 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 🐆@jlai.lu
      link
      fedilink
      arrow-up
      17
      ·
      1 year 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
        arrow-up
        9
        ·
        1 year 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.

      • Pxtl@lemmy.ca
        link
        fedilink
        English
        arrow-up
        3
        ·
        1 year 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.

      • roastpotatothief@lemmy.ml
        link
        fedilink
        arrow-up
        3
        arrow-down
        1
        ·
        1 year 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.

    • Shhalahr@beehaw.org
      link
      fedilink
      arrow-up
      1
      ·
      1 year 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.

    • UNWILLING_PARTICIPANT@sh.itjust.works
      link
      fedilink
      arrow-up
      1
      ·
      1 year ago

      This is great, but I just want to say that the best way to use git is to simply stop doing so much in one branch. Branches should not last longer than a week, ideally

  • erogenouswarzone@lemmy.ml
    link
    fedilink
    English
    arrow-up
    15
    arrow-down
    3
    ·
    edit-2
    1 year 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
        arrow-up
        4
        ·
        1 year 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
        arrow-up
        2
        ·
        1 year 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
        arrow-up
        1
        ·
        1 year 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”.