Live data from Hacker News

How to commit part of file in Git

newbeelearn.com

51–60 of 104 posts

Re: How to commit part of file in Git

#51
post #26

Earlier quoted context omitted.

Personally I’m happy with that. If the thing merged caused an issue, I’d want to revert the entire thing that was merged, not a subpart of it which would result in a state of the codebase that nobody reviewed. If you’re very diligent about making good atomic commits that always pass all test that can work, but I find that squashing PRs (and PRs being relatively small) is a very good trade off

Sounds reasonable. Also, when squashing a PR would conflate unrelated commits then maybe those commits should have been separate PRs instead. I've recently started to like squashing after usually preferring rebase merges, because with squashes I have an easy option to rewrite the commit message and edit out all of those meaningless "fix typo", "improve" and "now actually working" lines...

> I've recently started to like squashing after usually preferring rebase merges, because with squashes I have an easy option to rewrite the commit message

And why couldn't you rewrite the commit messages while rebasing?

EDIT: oh, you mean from the GitHub webUI, I presume. Got it.

Re: How to commit part of file in Git

#52
Also check out `git add --patch`'s cousins over in `git checkout` and `git reset`. I probably use reset --patch more than add, as I'll usually have a file full of relevant changes with only 1 hunk i want to 'unstage', so I'll stage the whole file and unstage the irrelevant hunk.

I use `git checkout --patch` mostly when splitting a big commit into smaller commits, retroactively. I start an interactive rebase, chuck 'break' before the big commit, then I start pulling the changes 'forward' from the big commit into the working directory with `git checkout --patch big-commit-hash */path.ext`. Sometimes this works out easier than popping a commit off and re-committing everything seperately, particularly if I already have a commit with a detailed message.

Re: How to commit part of file in Git

#53
post #25
post #18

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

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

Re: How to commit part of file in Git

#54
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 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.

Re: How to commit part of file in Git

#56
post #36
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.

Those are mutually exclusive.

Re: How to commit part of file in Git

#57
post #39

Earlier quoted context omitted.

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?

A Sync is a push+pull, changing branches is graphical.

Re: How to commit part of file in Git

#58
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.

Those are mutually exclusive.

Crafting good software and being productive? I guess it depends. I am much slower at producing code than most of my coworkers, but as a result they spend very little time maintaining/debugging it. But I spend most of my time debugging their crap (and they do, too).

I think there is a point to make that better code is often more profitable in the longer term. But the norm (at least where I work) is to swim in crappy code all day and complain about it while producing more of it.

Re: How to commit part of file in Git

#59

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

Re: How to commit part of file in Git

#60
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?

throw spaghetti at the wall till the phone app stays quiet!
Post reply on HN