Earlier quoted context omitted.
People will actually revert commits? For real? At work? Where do I get to sign up?
Relatively common practice where I work. What do you do instead?
How to commit part of file in Git
31–40 of 104 posts
Re: How to commit part of file in Git
#32Re: How to commit part of file in Git
#33Splitting up commits is totally underrated and seen rarely. I see colleagues over and over again plumbing 4 kinds of changes into the same commit. Good luck reverting the one change that caused an outage.
Re: How to commit part of file in Git
#34Earlier quoted context omitted.
Not the GP but we tend to use decently small and meaningful commits to make PRs easier to review. They then get squashed, so you can only (easily) revert the whole PR.
You're not the only ones, but I can't understand this approach. Do people never then read the version history? It must be impossible to understand commits' diffs with the changes all squashed together.
So the idea is really "what's the point of having a history full of broken state?".
> It must be impossible to understand commits' diffs with the changes all squashed together.
This would be a hint that your PR was too big and addressing more than one thing.
Re: How to commit part of file in Git
#35But that's the beauty of it: git makes it easy for anyone to use their favourite tool (be it CLI, TUI or GUI) :-).
Re: How to commit part of file in Git
#36Splitting up commits is totally underrated and seen rarely. I see colleagues over and over again plumbing 4 kinds of changes into the same commit. Good luck reverting the one change that caused an outage.
Crafting good commits is a skill that nobody seems to care about. In fact, nobody really seems to care about learning git at all despite it being one of the main tools in software development.
Re: How to commit part of file in Git
#37Earlier quoted context omitted.
You're not the only ones, but I can't understand this approach. Do people never then read the version history? It must be impossible to understand commits' diffs with the changes all squashed together.
Not the OP, but I think that the point of squashing every PR is that the reviewers/PR run the whole PR, not the individual commits. If you have a PR with 5 commits, 4 of which break the build and the last one fixes it, then merging that will be a problem if you need to git bisect later. So the idea is really "what's the point of having a history full of broken state?". > It must be impossible to understand commits' d…
And the answer is that you don't; each commit is individually testable and reviewable. Changes requested by reviewers are squashed into the commits and then merged into the project. Unfortunately, while the git command line has "range-diff" to ease review with this workflow, neither GitHub not Gitlab have an equivalent in their UI.
Re: How to commit part of file in Git
#38This article should mention `lazygit`. That's one of the best ways to customize hunks without committing to `emacs`. Magit's USP is that it's a great interface for those who already use (or are willing to use) `emacs`. `lazygit` is a great interface in its own right.
I use git rebase and git add/reset -p left and right.
I will definitely checkout lazygit though, thank you and others in this HN submission for the mention, looks useful.
Re: How to commit part of file in Git
#39VSCode handles this very well too: select the lines you want to commit and do "Git: Stage selected ranges"
Re: How to commit part of file in Git
#40I've used tig to do this for 15+ years. It's effortless. I know lazygit is more modern and has more features, but tig does this so well I have no need to change.
I kept running into an issue with tig where it couldn't break apart a hunk, or otherwise couldn't stage a part of one. I never figured it out by the time I gave lazygit a shot. Now that I've used lg in anger I only wish I had invested in it sooner.