3 ms·

All the things in between my commits is a messy soup. Looking there is not useful to anyone. I rewrite my history with git rebase so each commit is small and at

by Lindby 4mo ago

All the things in between my commits is a messy soup. Looking there is not useful to anyone. I rewrite my history with git rebase so each commit is small and atomic. The story I create with my commits is what explains why things are as they are, it doesn't matter if it's the true chronological story on how it actually happened. I agree with the author that reviewing pull requests is too late. The problem with pull request is that they make it hard to review individual commits since they are geared towards reviewing the result of an entire branch at once. But the answer is not to share all the noise, it should be to encourage small atomic commits so you can review the early work before the entire feature/fix is complete.

isityettime 4mo ago
> The problem with pull request is that they make it hard to review individual commits since they are geared towards reviewing the result of an entire branch at once. But the answer is not to share all the noise, it should be to encourage small atomic commits so you can review the early work before the entire feature/fix is complete. Isn't that just a GitHub problem, as opposed to Phabricator, Gerrit, etc.?
- danpalmer 4mo ago
  It is, but I think it's hard to explain to folks who have only used the Git/GitHub model – I know, I've been that person not really getting it. I think what's missed is two things: - In the Phabricator/Gerrit model you typically end up with changes that are smaller than a PR, but bigger than a commit. - You lose some history, or track it in a different way. With a PR you might add code to address comments in a new commit on the end, but with Phabricator/Gerrit you don't. If you already aggressively rebase in Git to absorb changes into commits that they make sense to go in, this won't be much of a change, and some systems give you views on the history happening within each change. But if you expect to see everything like that in the Git history, you may not get that, but the workflow changes around it and that's ok. I think both types of review are in a local maxima, where you lose some things to move to the other type, and it was fear of losing those from my workflow that made me resist the change a bit. When you get there though, you realise it's just not a problem.
seabass 4mo ago
The way you use commits sounds like how I tend to use stacked PRs at work. Good commit hygiene is hard to enforce at a team level, but for whatever reason at the PR level people are happy to write good descriptions and keep the sets of changes tidy.
- nightpool 4mo ago
  This is purely a function of what people expect to be looked at.... if your team started looking at each individual commit step by step, then you'd probably find that people started paying more attention to how their commit hygiene looks.
lmm 4mo ago
Why do you want those commits though? In my experience people only look at history a) to see who wrote the code / when it was last changed, which works equally well with any approach, b) to see which feature it was part of, for which you will click through to the PR anyway, or c) to bisect for when a bug was introduced, in which case unedited/unrebased "noise" commits are more useful because you have more guarantee that each commit compiles and the original train of thought is more useful than the fictional history when you're looking for something unintentional.
jasonkester 4mo ago
This is the response I expected to see here. Reading through the article, I'm reminded of my dismay reading this exact sentiment every time version control is discussed. So many people are so quick to throw away their history so that things look "tidy". It makes no sense, but somehow it fits a certain programmer-brain logic that is surprisingly common. My style is to commit often. Like dozens of times per day. Commits are the record of what happened, and I want as much of that record to exist as possible. I've been saved so many times by a git bisect that landed pointing at a tiny commit to a single line that looks completely innocuous, yet broke something in a subtle way that only got discovered way later. That's what source control is for, in my opinion. Finding stuff like that. So many of these things would have been really painful to find if I'd had to sift through every line of a big commit. So to watch people intentionally balling up an entire PR's worth of commits and squashing them together to throw away the only (in my mind) thing that version control is good for, is truly baffling. But yeah, there are plenty of people like the parent in that camp, so the author's plan to add even more granularity will be an uphill battle.
- vbezhenar 4mo ago
  > I've been saved so many times by a git bisect that landed pointing at a tiny commit to a single line that looks completely innocuous, yet broke something in a subtle way that only got discovered way later. I did git bisect exactly zero times in my life.
- palata 4mo ago
  > But yeah, there are plenty of people like the parent in that camp, so the author's plan to add even more granularity will be an uphill battle. I find it sad to see it as a battle. Can't we agree on the idea that different people may have different preferences? "Converting everyone to Linux or vim" would be an uphill battle... if it was worth fighting at all. I don't care what OS or text editor others use, as long as I can use the one that is best for me. If I am happy with commits, I don't want to fight with people who aren't... what would be the point?
- foobarbecue 4mo ago
  Github default squash commit template & merge strategy makes it easy to go from the squash commit to the feature branch. So you get best of both worlds -- clean master and granular history on the branch. Bisect on master tells you which branch broke it, and then bisect on the branch if you want to find the original commit. Same with blame. IMO squash 4 the win. Github squash defaults work well. Gitlab squash defaults don't.
thomasfromcdnjs 4mo ago
Regardless if it is a messy soup or not, if disk/cost is not an issue, I would have no problem with anyone (likely agents) looking at what I was doing, and forgive me, but my reasoning™. Not overly confident in my position, but I believe agents prefer the extra information albeit noise to some.
marliechiller 4mo ago
What I've observed both in the comments here, and in my professional network is that people tend to fall into two distinct camps: 1) Those that use git like a crude autosave who then squash on merge 2) Those that prefer neatly wrapped, fully functional atomic commits It seems those ideas are in direct opposition to one another with 1) being more common in my experience, perhaps as github naturally supports it better plus the fact that stacked commits can solve some of the problems 2) accounts for... but if I had a choice, 1) definitely makes more sense to me.

by Lindby 4mo ago

isityettime 4mo ago

> The problem with pull request is that they make it hard to review individual commits since they are geared towards reviewing the result of an entire branch at once. But the answer is not to share all the noise, it should be to encourage small atomic commits so you can review the early work before the entire feature/fix is complete. Isn't that just a GitHub problem, as opposed to Phabricator, Gerrit, etc.?

danpalmer 4mo ago
It is, but I think it's hard to explain to folks who have only used the Git/GitHub model – I know, I've been that person not really getting it. I think what's missed is two things: - In the Phabricator/Gerrit model you typically end up with changes that are smaller than a PR, but bigger than a commit. - You lose some history, or track it in a different way. With a PR you might add code to address comments in a new commit on the end, but with Phabricator/Gerrit you don't. If you already aggressively rebase in Git to absorb changes into commits that they make sense to go in, this won't be much of a change, and some systems give you views on the history happening within each change. But if you expect to see everything like that in the Git history, you may not get that, but the workflow changes around it and that's ok. I think both types of review are in a local maxima, where you lose some things to move to the other type, and it was fear of losing those from my workflow that made me resist the change a bit. When you get there though, you realise it's just not a problem.

seabass 4mo ago

The way you use commits sounds like how I tend to use stacked PRs at work. Good commit hygiene is hard to enforce at a team level, but for whatever reason at the PR level people are happy to write good descriptions and keep the sets of changes tidy.

nightpool 4mo ago
This is purely a function of what people expect to be looked at.... if your team started looking at each individual commit step by step, then you'd probably find that people started paying more attention to how their commit hygiene looks.

lmm 4mo ago

Why do you want those commits though? In my experience people only look at history a) to see who wrote the code / when it was last changed, which works equally well with any approach, b) to see which feature it was part of, for which you will click through to the PR anyway, or c) to bisect for when a bug was introduced, in which case unedited/unrebased "noise" commits are more useful because you have more guarantee that each commit compiles and the original train of thought is more useful than the fictional history when you're looking for something unintentional.

jasonkester 4mo ago

This is the response I expected to see here. Reading through the article, I'm reminded of my dismay reading this exact sentiment every time version control is discussed. So many people are so quick to throw away their history so that things look "tidy". It makes no sense, but somehow it fits a certain programmer-brain logic that is surprisingly common. My style is to commit often. Like dozens of times per day. Commits are the record of what happened, and I want as much of that record to exist as possible. I've been saved so many times by a git bisect that landed pointing at a tiny commit to a single line that looks completely innocuous, yet broke something in a subtle way that only got discovered way later. That's what source control is for, in my opinion. Finding stuff like that. So many of these things would have been really painful to find if I'd had to sift through every line of a big commit. So to watch people intentionally balling up an entire PR's worth of commits and squashing them together to throw away the only (in my mind) thing that version control is good for, is truly baffling. But yeah, there are plenty of people like the parent in that camp, so the author's plan to add even more granularity will be an uphill battle.

vbezhenar 4mo ago
> I've been saved so many times by a git bisect that landed pointing at a tiny commit to a single line that looks completely innocuous, yet broke something in a subtle way that only got discovered way later. I did git bisect exactly zero times in my life.
palata 4mo ago
> But yeah, there are plenty of people like the parent in that camp, so the author's plan to add even more granularity will be an uphill battle. I find it sad to see it as a battle. Can't we agree on the idea that different people may have different preferences? "Converting everyone to Linux or vim" would be an uphill battle... if it was worth fighting at all. I don't care what OS or text editor others use, as long as I can use the one that is best for me. If I am happy with commits, I don't want to fight with people who aren't... what would be the point?
foobarbecue 4mo ago
Github default squash commit template & merge strategy makes it easy to go from the squash commit to the feature branch. So you get best of both worlds -- clean master and granular history on the branch. Bisect on master tells you which branch broke it, and then bisect on the branch if you want to find the original commit. Same with blame. IMO squash 4 the win. Github squash defaults work well. Gitlab squash defaults don't.

thomasfromcdnjs 4mo ago

Regardless if it is a messy soup or not, if disk/cost is not an issue, I would have no problem with anyone (likely agents) looking at what I was doing, and forgive me, but my reasoning™. Not overly confident in my position, but I believe agents prefer the extra information albeit noise to some.

marliechiller 4mo ago

What I've observed both in the comments here, and in my professional network is that people tend to fall into two distinct camps: 1) Those that use git like a crude autosave who then squash on merge 2) Those that prefer neatly wrapped, fully functional atomic commits It seems those ideas are in direct opposition to one another with 1) being more common in my experience, perhaps as github naturally supports it better plus the fact that stacked commits can solve some of the problems 2) accounts for... but if I had a choice, 1) definitely makes more sense to me.