Live data from Hacker News

How to commit part of file in Git

newbeelearn.com

61–70 of 104 posts

Re: How to commit part of file in Git

#61
post #39

VSCode 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.

you can add the concept of sync yourself in git.

    [alias]
      sync = "git squash && git pull --rebase && git pop && git push" # YMMV
Git GUIs are always changing the interface to git. It gives you this weird lockin and islandification. Knowing how to actually use git can give you super powers.

Re: How to commit part of file in Git

#62

`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.

I came here to say this. `git gui` is nearly ubiquitous and has saved me for years from learning how to use `git add -p`. I don't use many graphical git tools but its options "stage hunk" and "stage line" are more intuitive and fine-grained than the hunk-splitting in `git add -p`

I'm a native git guy in general, but `git gui` has absolutely won my heart. I don't know what I'd do without it for staging partial commits. That and searching through stashes.

Re: How to commit part of file in Git

#63
post #50

Earlier quoted context omitted.

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 ski…

well im a dope, I never noticed the edit option. So if I edit the hunk and toggle the subset of changes I don't want, I'll get prompted to accept the diff of the diff? brb I need to go try this.

Re: How to commit part of file in Git

#64
post #50

Earlier quoted context omitted.

> 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 ski…

well im a dope, I never noticed the edit option. So if I edit the hunk and toggle the subset of changes I don't want, I'll get prompted to accept the diff of the diff? brb I need to go try this.

high five I won't need to worry about this again

Re: How to commit part of file in Git

#65

Splitting 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.

Mostly it’s just that git makes it unnecessarily hard to do atomic commits across a file

Re: How to commit part of file in Git

#66
post #37
post #34

Earlier 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…

> And the answer is that you don't; each commit is individually testable and reviewable.

How does this work in practice? Is every single atomic commit reviewed by someone? When do they review each of those commits? How many commits typically go into a PR?

> Changes requested by reviewers are squashed into the commits and then merged into the project.

So a reviewer finds the appropriate commit that their comment applies to, and then changes the actual commit itself? Who is the author of the commit at that point?

I'm trying to understand what you're talking about, because you seem to have something figured out, for a problem that every team I've worked on struggles with.

Re: How to commit part of file in Git

#67

VSCode 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…

Yikes that sounds like something that could shred an entire codebase

Re: How to commit part of file in Git

#68
post #25

Earlier 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.

I can only conclude that people who think squashing a work item into a single commit is great have never had to do serious bug hunting, relying on commit history for context, nor have they ever moved forges and lost the context from "the context is in the PR anyway".

I think I've done all those things except forges. I don't know what that one is. I still like squashing. I've wven become the git expert on my team. With squashed PR resolutions, I can more reliably use bisect. Many individual commits were never actually meaningful in the first place.

Re: How to commit part of file in Git

#69

Earlier quoted context omitted.

I can only conclude that people who think squashing a work item into a single commit is great have never had to do serious bug hunting, relying on commit history for context, nor have they ever moved forges and lost the context from "the context is in the PR anyway".

I think I've done all those things except forges. I don't know what that one is. I still like squashing. I've wven become the git expert on my team. With squashed PR resolutions, I can more reliably use bisect. Many individual commits were never actually meaningful in the first place.

GitLab, Bitbucket, GitHub, etc are forges

Re: How to commit part of file in Git

#70
post #48

For those in the JetBrains world, you can do this easily with changelists: https://www.jetbrains.com/help/idea/managing-changelists.htm...

Totally, been doing it for a long time in IntelliJ and the other JetBrains IDEs, still stunning colleagues by simply check marking blocks or lines to commit the way it conveys hopefully the most meaning, so there is little if any dependence between the logical units across the commits, so as to be able to revert easily if necessary. And then the PR tells a story rather look like a frightening blob of shuffled ASCII chars.
Post reply on HN