i keep comitting when i make a change. who cares. im solo dev. svn. git no thanks.
Software is made between commits
211–220 of 230 posts
Re: Software is made between commits
#212Re: Software is made between commits
#213Earlier quoted context omitted.
Also - at least in GitHub if you squash with the PR merge action in the UI - the original commit history is still available in the ref maintained by the closed PR yet doesn’t clutter your branch or tags namespace.
What are the numbers these days? What percent of projects are running on github versus say Atlassian?
I'm guessing the number of people who care about commit logs is dropping and the number who don't is skyrocketing.
Re: Software is made between commits
#214All 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…
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.
Re: Software is made between commits
#215This just sounds to me like "frequent auto-commits" with less trust in git. git can handle frequent auto-commits just fine . If you want to "rollup" frequent auto-commits into "cleaner" top-level commits but also keep all the point-in-time "conversation" of your auto-commits, then `git merge --no-ff` from time to time and use tools like `--first-parent` to focus in on "top-level" commits over "conversation" commits.…
This is what what I do. I never see the commits from branches but they are there if I need them. Even git blame can be setup to use --first-parent
Re: Software is made between commits
#216I love the title, there was another post that I thought was clever “If You are Asking for Human Attention, Demonstrate Human Effort”
Re: Software is made between commits
#217Earlier quoted context omitted.
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…
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…
That's interesting, so you keep the branches from before the squash -- but do you also rename them somehow, to show that they're now "frozen historic versions"?
Re: Software is made between commits
#218I spent the entire article thinking > this is what comments are for > that is usually unnecessary, but if it were, a comment would fulfill it > I literally solved this problem with a comment yesterday > if the AI needs to know that, I'd explicitly ask it to put it in a skill or AGENTS.md. if a human needs it, I'd put it in a comment > this is overengineering a purpose comments already fulfill I dont want a second set…
someone with your nickname would say :)
Re: Software is made between commits
#219Earlier quoted context omitted.
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…
That's interesting, so you keep the branches from before the squash -- but do you also rename them somehow, to show that they're now "frozen historic versions"?
That’s what I do, and I find this talk about “throwing away” code history baffling. It’s version control. Git branching is cheap.
I make a ton of backup copies. I rearrange the history to how I want before I share it (git history split is great). I keep my nonsense, others see a readable changeset. (Only downside is the occasional housecleaning of old branches, but after a while their usefulness diminishes.)
Re: Software is made between commits
#220> DeltaDB captures every operation in between and gives each one a stable identity Gives jj vibes, interesting!
especially when using Watchman https://docs.jj-vcs.dev/latest/config/#watchman