Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to commit part of file in Git

newbeelearn.com

Post reply on HN
Print view View original

71–80 of 104 posts

Re: How to commit part of file in Git

#71

Post by bonzini »

syndicatedjelly wrote: post #66
bonzini wrote: post #37

Earlier quoted context omitted.

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

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

1) yes 2) when a PR is submitted 3) it can be a lot for a huge project-wide refactoring, but generally I would say 1 to 5 is typical and up to 20 is not strange.

> So a reviewer finds the appropriate commit that their comment applies to, and then changes the actual commit itself?

No, the author applies the requested change and force-pushes once he has gotten all the requested changes applied.

> because you seem to have something figured out

Thanks! But it's not me—it's how Linux has used git from the beginning, for example. In fact it's the only workflow that is used by projects that still use email instead of GitHub/Gitlab PRs, but (trading some old pain with new pain) it is possible to use it even with the latter. The harder part is marching the review comments to the new patch, which is actually pretty easy to do with emails.

It's quite some work and there's some learning curve. But depending on the project it can be invaluable when debugging. It depends a lot on how much the code can be covered by tests, in particular.

Re: How to commit part of file in Git

#72

Post by ollysb »

palata wrote: post #36
cedws wrote: post #33

Earlier quoted context omitted.

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.

I would even go as far as "crafting good software is a skill that nobody seems to care about". It feels like people care a lot about "being productive" though, hence tools like all the Copilots.

The incentives are to get the code out the door then improve things later, if it's worth it. There's a lot of risk in product development, it iften doesn't make sense to craft the perfect software when there's a chance that it won't see the adoption that was hoped for.

Re: How to commit part of file in Git

#73

Post by quectophoton »

torblerone wrote: post #2

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.

And on this topic, another underrated feature that everyone seems to hate is merge commits.

If you use rebase on your own branch, but merge commits on the stable branch (whatever name you use for it), you get both things:

* Small individual commits with the size and ordering that the original author intended on their branch.

* A "commit group" that describes that set of changes for the sake of future maintainers' sanity, and that can be atomically reverted.

More so in PR-based flows. You can have `git log --first-parent` display only the PR merge commits[1], and `git log --no-merges` display the linear history.

[1]: Assuming you actually put useful info on those commits. If you use GitHub, those merge commits can be set to default to PR title and description.

Re: How to commit part of file in Git

#74

Post by quectophoton »

spinningarrow wrote: post #17
fuzzy2 wrote: post #13

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?

What I've seen the most is rolling back the deployment (if any) and writing a new commit with the fix.

Re: How to commit part of file in Git

#75

Post by newusertoday »

gooseyard wrote: post #63
palata wrote: 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.

in magit you can also select lines you want to commit. It's there in the article as well

Re: How to commit part of file in Git

#76

Post by iraqmtpizza »

dgellow wrote: post #5
IshKebab wrote: post #3

The only sane way to do this is with a proper IDE. Doing it via the command line is pure masochism.

Why? I use git add -p absolutely all the time, its really simple to learn

(1/1) Stage this hunk [y,n,q,a,d,s,e,?]?

(2/5) Stage this hunk [y,n,q,a,d,K,j,J,g,/,e,?]?

Wow, so intuitive! LOL. You really showed him.

This UX is laughably bad. It presents you every hunk, one at a time, without context, and if you want to include some lines and not others, you can't unless all the sub-hunks are exactly one line or you let it launch a text editor and you dick around in the raw diff which is its own domain-specific language.

Why don't people play starcraft like this?

(1/1) Move this zergling [u,d,l,r,b,a,J,g,/,e?]?

The fact that this needs a write-up and discussion is all you need to know. Where is the big how-to for committing partial files in GitHub Desktop? Oh, yeah, nobody needs one because it's obvious and right in front of your face.

If you have no limbs and can't use a mouse to click on things then this UI is great though.

Re: How to commit part of file in Git

#79

Post by dgellow »

iraqmtpizza wrote: post #76
dgellow wrote: post #5

Earlier quoted context omitted.

Why? I use git add -p absolutely all the time, its really simple to learn

(1/1) Stage this hunk [y,n,q,a,d,s,e,?]? (2/5) Stage this hunk [y,n,q,a,d,K,j,J,g,/,e,?]? Wow, so intuitive! LOL. You really showed him. This UX is laughably bad. It presents you every hunk, one at a time, without context, and if you want to include some lines and not others, you can't unless all the sub-hunks are exactly one line or you let it launch a text editor and you dick around in the raw diff which is its own…

It’s really easy to learn: one of the option is ‘?’, try it out, it will give you more explanation.

The ‘s’ to split changes is one of my favorite feature.

It takes a few minutes to get used to it, then becomes automatic: add the whole file ‘a’, skip file ‘d’, skip chunk ‘n’, stage chunk ‘y’, split ‘s’, stop here ‘q’, rollback ctrl-c.

The “chunk per chunk” approach is actually really nice, you’re focusing on what exactly you want to get your commit to be about.

You learn it once, that will never change, you’re set for decades.

Re: How to commit part of file in Git

#80

Post by iraqmtpizza »

dgellow wrote: post #79
iraqmtpizza wrote: post #76

Earlier quoted context omitted.

(1/1) Stage this hunk [y,n,q,a,d,s,e,?]? (2/5) Stage this hunk [y,n,q,a,d,K,j,J,g,/,e,?]? Wow, so intuitive! LOL. You really showed him. This UX is laughably bad. It presents you every hunk, one at a time, without context, and if you want to include some lines and not others, you can't unless all the sub-hunks are exactly one line or you let it launch a text editor and you dick around in the raw diff which is its own…

It’s really easy to learn: one of the option is ‘?’, try it out, it will give you more explanation. The ‘s’ to split changes is one of my favorite feature. It takes a few minutes to get used to it, then becomes automatic: add the whole file ‘a’, skip file ‘d’, skip chunk ‘n’, stage chunk ‘y’, split ‘s’, stop here ‘q’, rollback ctrl-c. The “chunk per chunk” approach is actually really nice, you’re focusing on what exa…

It's really easy to learn how to use a slot machine too. Or dwarf fortress. It's not productive -- it's a hobby at best.

EDIT:

You have extremely low standards for what constitutes a professional tool these days.

You also didn't address my point. split is brain damaged and doesn't work:

    + assertEquals(byte[].class, p.get0().getClass());
    + assertEquals(String.class, p.get1().getClass());
You try to split this hunk and it won't do it. This task is beyond trivial in any non-retarded GUI.

-p makes you more productive because you don't know how to use an electron app or Java app

Post reply on HN