4 ms·

it's way easier to revert the merge commit than potentially every commit that was included in it. having everything squashed into one commit can be annoying if

by chrsig 4y ago

it's way easier to revert the merge commit than potentially every commit that was included in it. having everything squashed into one commit can be annoying if the commit is too large, because it can be hard to identify why a specific change was made via git blame. With a merge commit, I can make individual commits for logical changes, potentially rebasing, or squashing commits together. that also gives an opportunity to write more intentional and informative commit messages. once i have a good changeset, I can publish a single PR for review. I've only really taken to this approach lately, for a long time I just didn't care. As the years go by, I care more and more about what git blame can tell me. I've been maintaining some projects for a long time, and I've had to pick up many projects that don't have their original authors available for consultation. In both cases, having a quality git commit log is just a time saver. I don't care about preserving the history from when the code was initially typed, I care about the context the log can provide me about the change sets that have been applied. I've been debating starting to include it in my code reviews: "this commit log needs more details: can you edit the commit message and do a git push --force?" If you're dealing with a more junior team, or people that don't care about the log, it's really a toss up for me. Roll your dice on maybe an informative message helping you, or sift through 15 commits saying "poke", or squash an enormous commit and get a single sentence about it.

q7xvh97o2pDhNrh 4y ago
> I've been debating starting to include it in my code reviews: "this commit log needs more details: can you edit the commit message and do a git push --force?" Strongly agree with this. I hold the line on this for every team I lead (which, sadly, is not every team I consult for, so sometimes I have to keep my mouth shut and spend my political capital elsewhere). Many junior/mid-level engineers have simply never seen commit messages and source control done well. Additionally, because many folks starting out in the field don't know how to truly use git beyond memorizing a few basic commands [1], they also never harvest any of the benefits of writing great commit messages. I've got a stash of links that I find myself often sending to engineers who are on the way up, and the tpope article on git commit messages [2] is one I find myself sharing around constantly. [1]: https://xkcd.com/1597/ https://xkcd.com/1597/ [2]: https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html https://tbaggery.com/2008/04/19/a-note-about-git-commit-mess...
Hamuko 4y ago
>I've been debating starting to include it in my code reviews: "this commit log needs more details: can you edit the commit message and do a git push --force?" I've accepted my role as the team's villain and regularly bitch about commit messages being too vague. Luckily they can't spit in my drinks since I work from home.
someweirdperson 4y ago
> having everything squashed into one commit can be annoying if the commit is too large, because it can be hard to identify why a specific change was made via git blame. Maybe it should be split into individual PRs. If there's dependencies between the changes there's tools to support stacked changes.
- chrsig 4y ago
  as with all issues, it depends :) I've been struggling with finding the sweet spot between number of pull requests and size of pull requests. The pipeline on my primary project takes an annoying amount of time to complete, ~30 mins or so if things go smoothly. It sounds like a lot, but it's got a very comprehensive set of tests. When PRs are too granular, the merge/rebase/test pipeline/merge cycles can be quite time consuming. Admittedly, I don't use stacked changes. They're something I only learned about somewhat recently, and haven't yet incorporated into my development cycles. Can you recommend any resources?
gravlaks 4y ago
> having everything squashed into one commit can be annoying if the commit is too large, because it can be hard to identify why a specific change was made via git blame. True, you can't via git blame. You can however go to the Github pull request, and look at the individual commits there. (If the the squashed commits containthes the PR/issue number.)
- chrsig 4y ago
  i've learned that anything not stored in the repo itself is ephemeral. org decides to leave github? hope you did a good job migrating all that. same goes for issues, wiki, etc. if it's not in the repo, there's a good chance it wont survive the test of time

by chrsig 4y ago

q7xvh97o2pDhNrh 4y ago

> I've been debating starting to include it in my code reviews: "this commit log needs more details: can you edit the commit message and do a git push --force?" Strongly agree with this. I hold the line on this for every team I lead (which, sadly, is not every team I consult for, so sometimes I have to keep my mouth shut and spend my political capital elsewhere). Many junior/mid-level engineers have simply never seen commit messages and source control done well. Additionally, because many folks starting out in the field don't know how to truly use git beyond memorizing a few basic commands [1], they also never harvest any of the benefits of writing great commit messages. I've got a stash of links that I find myself often sending to engineers who are on the way up, and the tpope article on git commit messages [2] is one I find myself sharing around constantly. [1]: https://xkcd.com/1597/ https://xkcd.com/1597/ [2]: https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html https://tbaggery.com/2008/04/19/a-note-about-git-commit-mess...

Hamuko 4y ago

>I've been debating starting to include it in my code reviews: "this commit log needs more details: can you edit the commit message and do a git push --force?" I've accepted my role as the team's villain and regularly bitch about commit messages being too vague. Luckily they can't spit in my drinks since I work from home.

someweirdperson 4y ago

> having everything squashed into one commit can be annoying if the commit is too large, because it can be hard to identify why a specific change was made via git blame. Maybe it should be split into individual PRs. If there's dependencies between the changes there's tools to support stacked changes.

chrsig 4y ago
as with all issues, it depends :) I've been struggling with finding the sweet spot between number of pull requests and size of pull requests. The pipeline on my primary project takes an annoying amount of time to complete, ~30 mins or so if things go smoothly. It sounds like a lot, but it's got a very comprehensive set of tests. When PRs are too granular, the merge/rebase/test pipeline/merge cycles can be quite time consuming. Admittedly, I don't use stacked changes. They're something I only learned about somewhat recently, and haven't yet incorporated into my development cycles. Can you recommend any resources?

gravlaks 4y ago

> having everything squashed into one commit can be annoying if the commit is too large, because it can be hard to identify why a specific change was made via git blame. True, you can't via git blame. You can however go to the Github pull request, and look at the individual commits there. (If the the squashed commits containthes the PR/issue number.)

chrsig 4y ago
i've learned that anything not stored in the repo itself is ephemeral. org decides to leave github? hope you did a good job migrating all that. same goes for issues, wiki, etc. if it's not in the repo, there's a good chance it wont survive the test of time