Context Around a year and a half ago, I’ve asked my former company for some time to work on an issue that was impacting the debugging capabilities in our project: gdbserver couldn’t debug multithreaded applications running on a PowerPC32 architecture. The connection to the gdbserver was broken and it couldn’t control the debug session anymore. Multiple people have already investigated this problem and I had a good starting point, but we still weren’t sure in which software component the issue lied: it could have been the toolchain, the gdbserver, the Linux kernel or the custom patches we applied on top of the kernel tree. We were quite far away from finding the root cause.
  • JackbyDev@programming.devEnglish
    4·
    1 year ago

    No, you’re correct, it definitely was all (or mostly) committed by Bram. That’s part of why I was saying it didn’t feel as bad but I didn’t think it was relevant to mention. But yes, you’re definitely correct.

    • aard@kyu.de
      1·
      1 year ago

      Git has different fields for author and committer - and modifying a commit should leave the author field intact, and just change the committer field. It is possible that github does something weird (I’m usually not doing much in their web UI) - but coming from working with git directly I’d expect you to be present in the author field.

      • JackbyDev@programming.devEnglish
        2·
        1 year ago

        I didn’t write the content of that commit. Author and committer being different is for things like rebasing commits written by other people.

        • aard@kyu.de
          2·
          1 year ago

          You mentioned a pull request, and that it got edited - which in my workflow is pulling the commit and amending it.

          • JackbyDev@programming.devEnglish
            1·
            1 year ago

            Okay, I probably misspoke about the technicalities. I opened a pull request, then they made a new commit and closed the PR (like it was an issue) and didn’t touch the commit. Hope that makes sense now.