16 ms·

If you keep merge commits you can get the full diff at once and see all the context you need, if you don't you can still write meaningful commit messages that i

by aulin 4y ago

If you keep merge commits you can get the full diff at once and see all the context you need, if you don't you can still write meaningful commit messages that identify the feature you're working on so that in the future you can still do a diff between the first and the last commit and see it all at once.

willio58 4y ago
Yeah if you just use commits as they are intended then the complexity of git drops off massively. I’ve used got for a decade and want to know how many times I’ve rebased? Zero
- aulin 4y ago
  I tend to stage everything I do in my local branches, experiments, hacks, partial changes I don't have time to finish right now, unfinished refactorings. No way I share that without rebasing it and cleaning it up first.
- mook 4y ago
  Isn't commits as they are intended a patch queue in email with a cover letter (0/n commit)? At least, that seemed to be how the Linux kernel works.
- __blockcipher__ 4y ago
  I am deeply suspicious of people who claim to have never rebased. I've never met such a person who didn't have absolutely disgusting commits: either (1) no commit body to explain the context of why a chance was made, for patches that clearly needed one, (2) random merge commits in the middle of the actual commits because they don't know any workflow besides merging master into their ongoing dev branch, or (3) massive pull requests (if using a pull request workflow) that touch 30 files and implement way more than just the feature the branch was supposed to be for. It's also a big sign to me that the person probably rarely if ever actually spelunks through the git log to understand why a certain change was made. Because if one does, they very quickly discover why a workflow involving sane rebasing onto origin/master produces such a better history. There's times when merge commits are appropriate, but they are few and far between compared to the endless abuses of merge commits by people who don't understand git in the slightest (my definition of "don't understand git" is someone who can't visualize the DAG)
- lelandfe 4y ago
  10 years of typos in commit messages

by aulin 4y ago

willio58 4y ago

Yeah if you just use commits as they are intended then the complexity of git drops off massively. I’ve used got for a decade and want to know how many times I’ve rebased? Zero

aulin 4y ago
I tend to stage everything I do in my local branches, experiments, hacks, partial changes I don't have time to finish right now, unfinished refactorings. No way I share that without rebasing it and cleaning it up first.
mook 4y ago
Isn't commits as they are intended a patch queue in email with a cover letter (0/n commit)? At least, that seemed to be how the Linux kernel works.
__blockcipher__ 4y ago
I am deeply suspicious of people who claim to have never rebased. I've never met such a person who didn't have absolutely disgusting commits: either (1) no commit body to explain the context of why a chance was made, for patches that clearly needed one, (2) random merge commits in the middle of the actual commits because they don't know any workflow besides merging master into their ongoing dev branch, or (3) massive pull requests (if using a pull request workflow) that touch 30 files and implement way more than just the feature the branch was supposed to be for. It's also a big sign to me that the person probably rarely if ever actually spelunks through the git log to understand why a certain change was made. Because if one does, they very quickly discover why a workflow involving sane rebasing onto origin/master produces such a better history. There's times when merge commits are appropriate, but they are few and far between compared to the endless abuses of merge commits by people who don't understand git in the slightest (my definition of "don't understand git" is someone who can't visualize the DAG)
lelandfe 4y ago
10 years of typos in commit messages