Fix i3bar workspace buttons for primary screen by orestisfl · Pull Request #6564 · i3/i3
github.com
git bisect: c734409 is the first bad commit c7344095ec242c5e2616841de27f11343a6010ee (HEAD) Fix leak sanitizer memleaks (#6520) i3bar/src/ipc.c | 5 +++-- i3bar/src/workspaces.c | 58 +++...
  • FizzyOrange@programming.dev
    362·
    2 days ago

    … if you have a super janky patch file workflow.

    If you are using Git like normal people do this can’t happen.

        • The_Decryptor@aussie.zoneEnglish
          2·
          39 minutes ago

          Sourcehut uses it, it’s actually the only way to interact with repos hosted on it.

          It definitely feels outdated, yet it’s also how git is designed to work well with. Like git makes it really easy to re-write commit history, while also warning you not to force push re-written history to a public repo (Like e.g. a PR), that’s because none of that is an issue with the email workflow, where each email is always an entirely isolated new commit.

      • Kissaki@programming.devEnglish
        16·
        2 days ago

        … which arguably makes them not “normal people” (referring to the earlier comment).

        Surely, most people use different, more integrated tooling.

      • FizzyOrange@programming.dev
        71·
        2 days ago

        Yeah it’s mad. Tbh I don’t think GitHub PRs are the best workflow, but I absolutely know that git send-email is the worst. I tried to use it once to contribute to OpenSBI, which inexplicably also insists on it. Suffice it to say my patch was never merged…

          • FizzyOrange@programming.dev
            4·
            1 day ago

            They wanted me to make some changes and with the normal workflow that’s just git commit and git push. With git send-email I have no fucking idea and it got beyond the point where I had enough cared enough to fight the process.

            • Tempy@programming.devEnglish
              2·
              2 hours ago

              I would have thought that you fix it locally, git commit, and regenerate the patch set again. Maybe with optional squashing of commits so each patch set doesn’t keep growing.

            • ElBarto@piefed.socialEnglish
              4·
              13 hours ago

              Oh I see! Thanks. I thought that they deliberately rejected your patch. But it was more about the red tape getting in the way. Yeah, that sounds frustrating.

  • Oinks@lemmy.blahaj.zone
    9·
    2 days ago

    Hooray to underspecified file formats.

    From patch(1):

    patch tries to skip any leading garbage, apply the diff, and then skip any trailing garbage. Thus you could feed an email message containing a diff listing to patch, and it should work.

    From git-am(1):

    The patch is expected to be inline, directly following the message. Any line that is of the form:

    • three-dashes and end-of-line, or
    • a line that begins with “diff -”, or
    • a line that begins with "Index: "

    is taken as the beginning of a patch, and the commit log message is terminated before the first occurrence of such a line.

    Ideally git-am should use a better file format, but I suppose the more realistic lesson now is to never have inline diffs in Commit messages.

  • verstra@programming.dev
    82·
    2 days ago

    Context: this happens if you use patch(1) with patches generated by git format-patch. If you do, you should be using git am instead.