`git gui` seems to be the easiest solution to me.
The interface is not pretty, but it does what one would expect and it’s fast.
How to commit part of file in Git
41–50 of 104 posts
Re: How to commit part of file in Git
#42VSCode handles this very well too: select the lines you want to commit and do "Git: Stage selected ranges"
VSCode's interface to Git is superior to Git-native. Adding the concept of Sync, simplifying branching, so many niceties.
i'm going to have to try vscode again, is this Sync you mention something other than the usual sync'ing of the user profile? what does vscode do differently with branches?
Re: How to commit part of file in Git
#43I find `git add -p` easy enough. Maybe I learned not to address random stuff while working on a particular thing, though. But that's the beauty of it: git makes it easy for anyone to use their favourite tool (be it CLI, TUI or GUI) :-).
I didn't know about git add -p when I started using magit and thought it was an amazing magit-specific feature and went around cluelessly telling everybody about it. Later when I was experimenting with a different editor I realized my folly, and have come to find that I prefer git add -p, since I often want to provide multiple paths or a glob etc when its time to add to the index.
Something I found that I like about the approach is that sometimes while working on a change, some unrelated code will catch my eye that I want to fix but not as part of my next commit. Being free to make the edit, knowing that I'll see it again later when staging changes, is nice because I would often otherwise forget to go back and revisit the thing I saw. The git add -p sessions then wind up being an opportunity to decide what changes go into each commit, etc. I do burn myself occasionally by having an unrelated edit that is in a hunk that can't be split- I suspect there are tweaks to diff I could make to help with that but have yet to overcome my apathy wrt research.
Re: How to commit part of file in Git
#44Earlier 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…
> So the idea is really "what's the point of having a history full of broken state?".
I rebase commits so they don't break the build but the history remains clean and incremental. Selective fixups and so on isn't the same as squashing everything into a single commit.
> This would be a hint that your PR was too big and addressing more than one thing.
I don't think so. Sure, that can be true, but squashes can also simply lose vital history. Suppose you remove a file and then replace it with code copied and modified from another file. If you then squash that, all Git will say is you made a massive edit to the file.
Re: How to commit part of file in Git
#45Splitting 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.
just don’t spend more time splitting up commits than you would have reverting change
usually you should err on the side of keeping the commits together, unless you’re close to release, patching a bug in release, etc.
Re: How to commit part of file in Git
#46VSCode handles this very well too: select the lines you want to commit and do "Git: Stage selected ranges"
I'd be careful with that feature though because it used to have an absolutely awful bug (and it might still tbh, I haven't had it confirmed that it's fully fixed yet).
https://github.com/microsoft/vscode/issues/96104
If you staged selected ranges it could change the line endings of the whole file from CRLF to LF. It's very easy to miss since it doesn't show in the normal diff, but then you end up with merge conflicts galore later on.
Re: How to commit part of file in Git
#47Earlier quoted context omitted.
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…
> 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. 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 t…
Well, I was obviously meaning that "workflows that squash the commits in a PR are workflows where each individual commit is not tested/reviewed separately".
Of course, if your workflow is different, then... well it is different. Doesn't make the "squash workflows" irrational.
Disclaimer: I don't squash PRs.
Re: How to commit part of file in Git
#48For those in the JetBrains world, you can do this easily with changelists: https://www.jetbrains.com/help/idea/managing-changelists.htm...
Re: How to commit part of file in Git
#49Earlier quoted context omitted.
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…
> So the idea is really "what's the point of having a history full of broken state?". I rebase commits so they don't break the build but the history remains clean and incremental. Selective fixups and so on isn't the same as squashing everything into a single commit. > This would be a hint that your PR was too big and addressing more than one thing. I don't think so. Sure, that can be true, but squashes can also simp…
> I rebase commits so they don't break the build but the history remains clean and incremental.
Sure, and that's fine. The idea of the squash workflow is that they don't expect that. It's just different, and that's the rationale behind it :-).
> all Git will say is you made a massive edit to the file.
Which IMO is exactly what happened in this case xD. But again... whatever floats your boat, I was just talking from the point of view of a squash workflow.
Re: How to commit part of file in Git
#50I find `git add -p` easy enough. Maybe I learned not to address random stuff while working on a particular thing, though. But that's the beauty of it: git makes it easy for anyone to use their favourite tool (be it CLI, TUI or GUI) :-).
I didn't know about git add -p when I started using magit and thought it was an amazing magit-specific feature and went around cluelessly telling everybody about it. Later when I was experimenting with a different editor I realized my folly, and have come to find that I prefer git add -p, since I often want to provide multiple paths or a glob etc when its time to add to the index. Something I found that I like about…
> I do burn myself occasionally by having an unrelated edit that is in a hunk that can't be split- I suspect there are tweaks to diff I could make to help with that but have yet to overcome my apathy wrt research.
`git add -p` allows you to "edit [e]" the patch, meaning that you can really decide exactly what should be added. And that's a great opportunity to learn how to manipulate patches, which is an important skill IMO!