• AVincentInSpace@pawb.social
    link
    fedilink
    English
    arrow-up
    63
    arrow-down
    2
    ·
    edit-2
    1 year ago

    Every time I commit I have to look through git diff, figure out what the hell I actually did, come up with something intelligent to say about jt, possibly split the commit into multiple commits if I changed multiple things, do some shuffling with git reset and git add

    For some reason all my personal projects are all like 4K SLoC with 50 total commits, all of which include apologies for not doing more smaller commits

    • SokathHisEyesOpen@lemmy.ml
      link
      fedilink
      English
      arrow-up
      45
      arrow-down
      1
      ·
      1 year ago

      There’s a bigger issue than your commit message if you don’t even know what you just coded and are committing.

      • AVincentInSpace@pawb.social
        link
        fedilink
        English
        arrow-up
        28
        ·
        edit-2
        1 year ago

        You see, sometimes I code something, go to bed before finishing it, come back, decide not to commit because then I’d have to think of a commit message and I just want to code, start working on an unrelated feature, do that for a couple days, get distracted by life stuff and put the project down for a few weeks/months, rinse and repeat, and then I finally get around to writing a commit message because I’m about to start a huge change and I want a restore point and I’m like. Okay, it’s been like 3 months since my last commit, I’m pretty sure my code can now do something it couldn’t 3 months ago but come on, I can’t even remember what I had for lunch last Thursday

        I’m well aware this is terrible practice but I don’t know how to stop doing it

        • dukk@programming.dev
          link
          fedilink
          arrow-up
          20
          ·
          1 year ago

          Commit more often. Maybe work in a different feature branch, and don’t be afraid to commit your half-working crappy code. If it’s a personal project/fork, it’s totally acceptable to commit often with bad commit names and small unfinished changes: you can always amend/squash the commits later. That’s how I tend to work: create a new branch, work on the feature, rebase and merge (fast forward, no merge commit). Also, maybe don’t jump around working on random features :P

        • SokathHisEyesOpen@lemmy.ml
          link
          fedilink
          English
          arrow-up
          3
          ·
          1 year ago

          You can help yourself a lot here by making commits every time you make a meaningful change. A feature doesn’t need to be complete to commit major checkpoints along the path to completion. That’s what feature branches are for. Commit often. It’ll help you think of messages, and it’ll help you recover in the case of catastrophe.

        • adrian783@lemmy.world
          link
          fedilink
          arrow-up
          1
          arrow-down
          1
          ·
          1 year ago

          you can setup a on-save script to force you to commit when the number of changes is greater than a certain number from the previous commit.

      • akkajdh999@programming.dev
        link
        fedilink
        arrow-up
        13
        ·
        1 year ago

        I just get too excited about actually implementing/fixing something (random things that I see along the way) more than commit ceremony (nobody will care about it in my project anyway other than one random guy who gave the repo a star)

        • oce 🐆@jlai.lu
          link
          fedilink
          arrow-up
          5
          ·
          1 year ago

          Nah, I’m that guy, I gave your repo a star for the effort, but I’m not reading your history.

      • adrian783@lemmy.world
        link
        fedilink
        arrow-up
        3
        arrow-down
        1
        ·
        1 year ago

        it means you commit too infrequently. your commit messages should be able to describe what u just did within 10 words.

        • PoolloverNathan@programming.dev
          link
          fedilink
          English
          arrow-up
          3
          ·
          1 year ago

          Patch add - it shows you particular changes you made, and you choose whether or not to include them in the commit. (You can then use git stash -k to stash only the changes you did not add, so you can test before you commit.)

    • PixxlMan@lemmy.world
      link
      fedilink
      arrow-up
      3
      ·
      1 year ago

      I spend much time splitting them up inside visual studio by file and individual lines changed to try and separate my many simultaneous changes into several somewhat usable commits. If I was stupid enough to make some big refactor at the same time I might just have to throw in the towel… It’s really painful after a few weeks to try and pick up the pieces of what I was doing but never commited too lol.

      • foxymulder@lemmy.ml
        link
        fedilink
        English
        arrow-up
        39
        ·
        1 year ago

        “patch mode” - Patch mode allows you to stage parts of a changed file, instead of the entire file. This allows you to make concise, well-crafted commits that make for an easier to read history.

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

          Highly recommend throwing --patch on any git commands you’re used to using. You will have the prettiest, most atomic fkn commit, I’m serious people will love you for it.

          I mean many people won’t care, but the quality folk will notice and approve.

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

              Trunk based, eh? Yeah, we do that on a couple teams where I’m at, too. I like the philosophy, but force pushing the same commit over and over as you’re incorporating review feedback is antisocial, especially when you’ve got devs trying to test your changes out on their machines.

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

              I’ve only tried the VS code hunk stager thing, and found it cumbersome compared to command line, but if you can make a GUI work for you ya go for it. I’ve never found it worth the trouble personally

              • oce 🐆@jlai.lu
                link
                fedilink
                arrow-up
                2
                ·
                1 year ago

                You should try the JetBrains IDEs, as the other said, you can pick changes line by line graphically, when you commit, when you do a diff with another branch or when you fix conflicts. It’s much more convenient than commands and terminal text editors.

      • sip@programming.dev
        link
        fedilink
        arrow-up
        6
        ·
        1 year ago

        uuuuuuuu. and you could do -m to describe the commit.

        next they’ll add --push/-P.

        perhaps add -r for fetch/rebase then commit.

        one command to rule them all! 😈

  • syd@lemy.lol
    link
    fedilink
    arrow-up
    12
    arrow-down
    1
    ·
    1 year ago

    I’m using Copilot for it right now. It works on half of the cases.

  • pete_the_cat@lemmy.world
    link
    fedilink
    English
    arrow-up
    11
    ·
    1 year ago

    For me, it was my boss gave me a programming task which he knew would take hours or a day or two… and then 15 minutes later tells me to “switch focus” and do a menial task that any of my five coworkers could do 🤦‍♂️

  • paul@techy.news
    link
    fedilink
    English
    arrow-up
    10
    arrow-down
    2
    ·
    1 year ago

    do git commit -v and then just summarize the diff you have in your editor in a human readable form.

    • DontTakeMySky@lemmy.world
      link
      fedilink
      arrow-up
      10
      ·
      1 year ago

      Don’t just summarize the content though, summarize the rationale or how things connect. I can read your diff myself to see what changed, I want to know the logical connections, the reason you did X and not Y, etc.

      Or just say “stuff” and provide that context in the PR description separately, no need to overdo the commit log on a feature branch if you’re using squash merges from your PR.

      • deadbeef79000@lemmy.nz
        link
        fedilink
        arrow-up
        8
        ·
        edit-2
        1 year ago

        P1000x this.

        I can read a diff.

        I need to know why.

        No, a code comment isn’t good enough, it’s out of date after the next commit.

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

          Code comments for "why"s that persist. Commits for why’s that are temporary.

          If you need to run X before Y, add a comment. If you added X before why because it was easier, leave it in a commit

            • DontTakeMySky@lemmy.world
              link
              fedilink
              arrow-up
              2
              ·
              1 year ago

              With a comment on the test detailing why it matters so people don’t just assume the test is out of date when it fails.

              And ideally test the underlying result of x before y, not the fact that x is called before y.

              And while we’re at it, assert in Y that X has been called, and again comment the reason for the preconditions.

    • aes@lemm.ee
      link
      fedilink
      English
      arrow-up
      5
      ·
      edit-2
      1 year ago

      git commit -m "directory_x:file_i.so: did x, y, and z; directory_x:file_ii.so: fixed t"

  • catastrophicblues@lemmy.ca
    link
    fedilink
    arrow-up
    7
    ·
    1 year ago

    Oh god I feel so called out. I wish I paid more attention to my commit messages but I’m usually too busy fixing the directory structure and refactoring. Sigh.

    • brlemworld@lemmy.world
      link
      fedilink
      arrow-up
      2
      ·
      1 year ago

      My company collapses into a single commit at merge so idgaf what the commit message is anymore. Though I would prefer not collapsing them.

      • DoomBot5@lemmy.world
        link
        fedilink
        English
        arrow-up
        3
        arrow-down
        1
        ·
        1 year ago

        Master should just have the feature description commits, not the hundred commits it took to get there after refactoring the code for the 3rd time and pulling changes from master since it’s taken so long to get done.

      • catastrophicblues@lemmy.ca
        link
        fedilink
        arrow-up
        1
        ·
        1 year ago

        Yeah I worked at a place like that, but it made sense because we were also expected to keep PRs small, so a good commit message for several squashed ones was perfectly fine.

      • Gyoza Power@discuss.tchncs.de
        link
        fedilink
        arrow-up
        1
        ·
        1 year ago

        I prefer that approach. We work with smaller tasks, so it makea more sense, plus it helps keep the master clean and if you want a more detailed view of the specific commits, you just have to click on the link to the PR. It’s a better way to organise it IMO