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

91–100 of 104 posts

Re: How to commit part of file in Git

#91

Post by palata »

ollysb wrote: post #72
palata wrote: post #36

Earlier quoted context omitted.

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.

There is a difference between "crafting the perfect software" and "crafting good software". It is way too common to not realize it and settle on "crafting crappy software" instead. The problem being that crappy software is often very hard to improve later, if it's worth it.

I have lived through multiple examples of this, the biggest one being a bad protocol (that was provably badly designed at the beginning) that got adoption, many tools built around it, and ten years later everybody hates it and keeps complaining but it's so hard to replace because of all the tooling built around it.

Re: How to commit part of file in Git

#92

Post by palata »

gooseyard wrote: post #64
gooseyard wrote: post #63

Earlier quoted context omitted.

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

I'm glad it helps! \o/

Re: How to commit part of file in Git

#93

Post by palata »

bonzini wrote: post #71
syndicatedjelly wrote: post #66

Earlier quoted context omitted.

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

Yeah, I think that the email workflow (which I love) is more adapted to this!

Re: How to commit part of file in Git

#94

Post by Chris_Newton »

iraqmtpizza wrote: post #80
dgellow wrote: post #79

Earlier quoted context omitted.

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…

Is there something unusual about your example that means (e)dit doesn’t work if you want to treat those lines as separate hunks? Usually if you have multiple logical changes that are adjacent and get recognised as a single change by default, you can just open your editor and keep the lines you want to stage, much the same as you’d do by marking the lines you want to stage in most of the interactive GUIs built on top of Git.

Re: How to commit part of file in Git

#95

Post by SAI_Peregrinus »

palata wrote: post #54
000ooo000 wrote: post #53

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 it's a bit of a limited conclusion. Maybe they really just make small PRs that make sense, and maybe they rewrite the commit message into something useful when squashing.

My employer has all PRs merged by a bot once they're approved. The bot takes the PR description and uses that as the commit message. The PR is the unit of change that gets reviewed, not the commit. This makes for a nice linear bisectable history of commits (one per PR) with descriptions, references to issues on our tracker, etc. And no need to worry about force pushing, rebasing, etc, unless you want to do so.

Of course it's got the same end result as doing an interactive rebase & combining all the in-progress commits into a single reviewable unit of change with a good commit message, but it's a bit more automatic.

Re: How to commit part of file in Git

#96

Post by IshKebab »

dgellow wrote: post #81
iraqmtpizza wrote: post #80

Earlier quoted context omitted.

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’s a professional tool not a hobby, I don’t understand the analogy. Learning to use -p makes you more productive.

It makes you more productive than not splitting commits at all. It doesn't make you more productive than doing it in a GUI.

It's like you're saying "guys you should use this new hand drill I've discovered! It's so much more productive than digging holes with an awl!" while ignoring the fact that electric drills exist.

Re: How to commit part of file in Git

#97

Post by IshKebab »

loloquwowndueo wrote: post #9
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.

It’s perfectly doable in the command line. Utilities like git-gui make it fairly easy to stage and commit chunks or lines. Git plug-ins for vim or eMacs (the article mentions magit) are also quite efficient. You don’t need a bloated IDE for this.

Yes I would agree with "perfectly doable". I don't really like tools that are "perfectly doable"; I prefer "easy".

Re: How to commit part of file in Git

#98

Post by IshKebab »

n4r9 wrote: post #27
dgellow wrote: post #5

Earlier quoted context omitted.

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

Also use git add -p frequently. I can't understand why people are even discussing using other tools.

It's because other tools are much better.

Re: How to commit part of file in Git

#99

Post by iraqmtpizza »

Chris_Newton wrote: post #94
iraqmtpizza wrote: post #80

Earlier quoted context omitted.

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…

Is there something unusual about your example that means (e)dit doesn’t work if you want to treat those lines as separate hunks? Usually if you have multiple logical changes that are adjacent and get recognised as a single change by default, you can just open your editor and keep the lines you want to stage, much the same as you’d do by marking the lines you want to stage in most of the interactive GUIs built on top…

You shouldn't have to edit a raw diff which is its own language just to split two adjacent lines. I'm not saying it should be fixed, I'm saying people should stop using the command line to do this entirely. (I find it quite funny that they ever did.)

Oh, I forgot that it probably couldn't be fixed even if they wanted to because if split suddenly started working it would break someone's spacebar heating script.

Re: How to commit part of file in Git

#100

Post by Chris_Newton »

iraqmtpizza wrote: post #99
Chris_Newton wrote: post #94

Earlier quoted context omitted.

Is there something unusual about your example that means (e)dit doesn’t work if you want to treat those lines as separate hunks? Usually if you have multiple logical changes that are adjacent and get recognised as a single change by default, you can just open your editor and keep the lines you want to stage, much the same as you’d do by marking the lines you want to stage in most of the interactive GUIs built on top…

You shouldn't have to edit a raw diff which is its own language just to split two adjacent lines. I'm not saying it should be fixed, I'm saying people should stop using the command line to do this entirely. (I find it quite funny that they ever did.) Oh, I forgot that it probably couldn't be fixed even if they wanted to because if split suddenly started working it would break someone's spacebar heating script.

It seems a stretch to call having a + character at the start of an added line “its own language”. Staging one line of the two in your example probably takes less than five seconds using this method; in the editor, you just delete the line you don’t want.

If you personally prefer a GUI then that’s obviously your choice. Some people do and I doubt you’ll find many people claiming Git has the world’s best UI. It does work everywhere, though, and I doubt it’s any slower than using a GUI for a task like your example. Either way, you can have lines staged or not pretty much as fast as you can read them and decide whether they should be.

Post reply on HN