26 ms·

git commit -m WIP I hope you're rebasing that terrible commit message away before pushing this remotely.

by asaph 8y ago

james_s_tayler 8y ago
I hope the pre-commit hook validates the commit message follows the correct format which links the work to the correct ticket number and if you left off the ticket number inserts it for you based off the branch name etc.
- ninkendo 8y ago
  No. No. NO. My commits locally are my business, and 100000% orthogonal to what YOU (my teammate) will see when I'm ready to make a PR. Because I rebase, I reword commits, and I squash things as necessary before I submit a pull request. The horrible conflation of commits (what I do when I want to save my work) and pull/merge requests (what I do when I want to integrate my work into the repo that everyone sees) is the very reason why git was created to begin with. If you want centralized version control where "commit" means "everyone sees it and it has to pass checks", use SVN. Seriously, get away from my tools.
  - james_s_tayler 8y ago
    Yeah, but none of that would be affected right? If you don't prepend the ticket number, it'll do it for you. That gives the entire team a guarantee all the work is traceable. It's a tool that serves the whole team, not just you.
    - ninkendo 8y ago
      Why should this be done at pre-commit time? And what automated system will be able to guess a ticket number based only on what's in a commit? I'm all for validation that all commits must have some metadata/ticket numbers attached... at the time it is merged into master. Not on my local machine. I probably did `git add -A && git commit -m WIP` at least 7 or 8 times today alone. But all my commits that made it into a PR were squashed, divided up logically, and renamed before they went in. I'm trying to imagine a system where some automated thing prepends "TICKET#123 WIP" before every commit I make, locally, even if they're all getting thrown away before I squash/rebase/reword my commits. What's the point?
ninkendo 8y ago
Of course! I hope you don't avoid using your version control system because you're waiting until you have a perfect, sensible commit and you don't want/know how to squash them later. My commits locally are 100% my damned business. I don't want any automated system messing with the way I commit anything. Ever. When I push to the server (and particularly when I open up a PR), I will have squashed my commits, or separated and arranged them sensibly so that they're easy to read and understand, and they must pass linting/PR checks before they get merged to master. Commit hooks are the absolute worst way to accomplish this goal, and fuck any system that confuses the two concepts (what I'm committing locally vs what goes to master), and any system that gets in the way of my local development loop. Go back to SVN if you want every commit you make to be instantaneously put in master and distributed to every other developer.

git commit -m WIP I hope you're rebasing that terrible commit message away before pushing this remotely.

by asaph 8y ago

git commit -m WIP I hope you're rebasing that terrible commit message away before pushing this remotely.

I hope the pre-commit hook validates the commit message follows the correct format which links the work to the correct ticket number and if you left off the ticket number inserts it for you based off the branch name etc.

ninkendo 8y ago
No. No. NO. My commits locally are my business, and 100000% orthogonal to what YOU (my teammate) will see when I'm ready to make a PR. Because I rebase, I reword commits, and I squash things as necessary before I submit a pull request. The horrible conflation of commits (what I do when I want to save my work) and pull/merge requests (what I do when I want to integrate my work into the repo that everyone sees) is the very reason why git was created to begin with. If you want centralized version control where "commit" means "everyone sees it and it has to pass checks", use SVN. Seriously, get away from my tools.
- james_s_tayler 8y ago
  Yeah, but none of that would be affected right? If you don't prepend the ticket number, it'll do it for you. That gives the entire team a guarantee all the work is traceable. It's a tool that serves the whole team, not just you.
  - ninkendo 8y ago
    Why should this be done at pre-commit time? And what automated system will be able to guess a ticket number based only on what's in a commit? I'm all for validation that all commits must have some metadata/ticket numbers attached... at the time it is merged into master. Not on my local machine. I probably did `git add -A && git commit -m WIP` at least 7 or 8 times today alone. But all my commits that made it into a PR were squashed, divided up logically, and renamed before they went in. I'm trying to imagine a system where some automated thing prepends "TICKET#123 WIP" before every commit I make, locally, even if they're all getting thrown away before I squash/rebase/reword my commits. What's the point?

ninkendo 8y ago

Of course! I hope you don't avoid using your version control system because you're waiting until you have a perfect, sensible commit and you don't want/know how to squash them later. My commits locally are 100% my damned business. I don't want any automated system messing with the way I commit anything. Ever. When I push to the server (and particularly when I open up a PR), I will have squashed my commits, or separated and arranged them sensibly so that they're easy to read and understand, and they must pass linting/PR checks before they get merged to master. Commit hooks are the absolute worst way to accomplish this goal, and fuck any system that confuses the two concepts (what I'm committing locally vs what goes to master), and any system that gets in the way of my local development loop. Go back to SVN if you want every commit you make to be instantaneously put in master and distributed to every other developer.