Software is made between commits
191–200 of 230 posts
Re: Software is made between commits
#192Re: Software is made between commits
#193Earlier quoted context omitted.
We're the opposite. No rebasing your PR. It changes the hashes which we use for ci/cd. Keep it linear, show me the full history, show me where you merged main back into it, and then we force squash on merge. Main then has a nice single commit with a reference to the branch it came from if you wish to see how it developed. Why would we want to litter main with your 100 commits? You own your code, and if you wish to di…
> Main then has a nice single commit with a reference to the branch it came from if you wish to see how it developed. Yeah sorry that's a toy project. You have 50 people push commits for six years and see if those branches don't 'accidentally' get deleted. We need a different VCS tool to get what you're after there.
The main branch remains compact with a linear history without the commit noise. Deleted branches can be restored, commits that otherwise do not exist in the history can be interacted with, and so on.
Re: Software is made between commits
#194All 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 re…
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.
Re: Software is made between commits
#195All 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 re…
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. Commit…
I did git bisect exactly zero times in my life.
Re: Software is made between commits
#196Earlier quoted context omitted.
We're the opposite. No rebasing your PR. It changes the hashes which we use for ci/cd. Keep it linear, show me the full history, show me where you merged main back into it, and then we force squash on merge. Main then has a nice single commit with a reference to the branch it came from if you wish to see how it developed. Why would we want to litter main with your 100 commits? You own your code, and if you wish to di…
> Main then has a nice single commit with a reference to the branch it came from if you wish to see how it developed. Yeah sorry that's a toy project. You have 50 people push commits for six years and see if those branches don't 'accidentally' get deleted. We need a different VCS tool to get what you're after there.
Re: Software is made between commits
#197Re: Software is made between commits
#198Re: Software is made between commits
#199Earlier quoted context omitted.
Ugh, let's take a step back and make a distinction: I don't need your fluff. No one cares how you arrived writing another crud line to save an object to database or sent yet another AJAX call. If you wrote some genuine great compression algorithm that's a different take on compression, I would like to see step by step reasoning and eventual dead ends.
I think a good argument ad absurdum for this is to look at how some recipe sites give the entire genealogical history of the author and an anecdote about how their gammy met Theodore Roosevelt and he stole her pen. Three pages later I discover I need to go to the grocery store because the recipe requires sour cream. And the store is closed so I need a different recipe. Don't fucking do that. Do something way less tha…
Re: Software is made between commits
#200So maybe just switch to a code review tool and use its interface to converse with the bots?