[HN Gopher] How to commit part of file in Git
___________________________________________________________________
How to commit part of file in Git
Author : thunderbong
Score : 23 points
Date : 2024-02-15 11:35 UTC (1 days ago)
(HTM) web link (newbeelearn.com)
(TXT) w3m dump (newbeelearn.com)
| torblerone wrote:
| 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.
| fuzzy2 wrote:
| People will actually revert commits? For real? At work? Where
| do I get to sign up?
| spinningarrow wrote:
| Relatively common practice where I work. What do you do
| instead?
| shric wrote:
| 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.
| williamdclt wrote:
| 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
| matrss wrote:
| 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...
| lubutu wrote:
| 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.
| palata wrote:
| 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' diffs with
| the changes all squashed together.
|
| This would be a hint that your PR was too big and
| addressing more than one thing.
| bonzini wrote:
| > 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 this
| workflow, neither GitHub not Gitlab have an equivalent in
| their UI.
| mewpmewp2 wrote:
| Work around it.
| sgustard wrote:
| I count 300 reverts out of 45,430 commits in our codebase.
| So I don't know what counts as normal or common but
| certainly our intent is to keep it rare, catch issues in
| testing, or patch code without reverting.
| cedws wrote:
| 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.
| palata wrote:
| 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.
| IshKebab wrote:
| The only sane way to do this is with a proper IDE. Doing it via
| the command line is pure masochism.
| dgellow wrote:
| Why? I use git add -p absolutely all the time, its really
| simple to learn
| arcanemachiner wrote:
| Use lazygit, it's faster.
| mstade wrote:
| Me too, in fact I find it much easier to do with the terminal
| than a GUI.
| werdnapk wrote:
| I use `git add -p` regardless if the whole file gets
| committed or not since I use it as a visual review tool to
| verify what I've changed.
| mksybr wrote:
| TIL from another story on HN:
|
| commit.verbose true This adds the whole commit diff in the
| text editor where you're writing your commit message, to
| help you remember what you were doing.
|
| https://jvns.ca/blog/2024/02/16/popular-git-config-
| options/#...
| sodapopcan wrote:
| It's not the only sane way, it's just what IDE zealots say...
| even though you don't even need an IDE to do it the "IDE
| way". There are plugins to highlight and stage diffs in most
| text editors.
|
| Regardless I also really like `git add -p`. I don't use it
| often but it really makes me focus on and consider each hunk.
| It was the defacto way to do it at an old company I worked at
| and no, it was not a small startup "hipster" company, we
| built enterprise ERP software.
| n4r9 wrote:
| Also use git add -p frequently. I can't understand why people
| are even discussing using other tools.
| arcanemachiner wrote:
| lazygit is my answer to this problem... and so many others.
| loloquwowndueo wrote:
| 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.
| smcameron wrote:
| stgit makes it trivial.
| Rebelgecko wrote:
| I do hg split (which I think this is based on? Or at least it's
| very similar) all the time and it's fine. I guess an IDE makes
| it a little easier to select regions that don't line up with
| hunks?
| SSchick wrote:
| Is there a git equivalent?
| wilg wrote:
| GitHub Desktop does this very well. Highly recommend!
| poidos wrote:
| magit with vim mode is awesome for this. just visually select the
| lines, commit, done. so good.
| ggregoire wrote:
| VSCode handles this very well too: select the lines you want to
| commit and do "Git: Stage selected ranges"
| petepete wrote:
| I've used tig to do this for 15+ years. It's effortless. I know
| lazygit is more modern and has more features, but tig does this
| so well I have no need to change.
| collinvandyck76 wrote:
| I kept running into an issue with tig where it couldn't break
| apart a hunk, or otherwise couldn't stage a part of one. I
| never figured it out by the time I gave lazygit a shot. Now
| that I've used lg in anger I only wish I had invested in it
| sooner.
| icywonder wrote:
| git-cola handles that nicely too.
| parentheses wrote:
| This article should mention `lazygit`. That's one of the best
| ways to customize hunks without committing to `emacs`.
|
| Magit's USP is that it's a great interface for those who already
| use (or are willing to use) `emacs`. `lazygit` is a great
| interface in its own right.
| grimgrin wrote:
| the only reason I do some git stuff in vim and not _always_ in
| the shell, is because tpope is very thoughtful and fugitive.vim
| provides nice ways to deal with hunks or hunk partials (visually
| selecting a range within a hunk, for i.e.)
|
| https://github.com/tpope/vim-fugitive/blob/master/doc/fugiti...
| RheingoldRiver wrote:
| does anyone use Sublime Merge for this? do you like it?
___________________________________________________________________
(page generated 2024-02-16 23:00 UTC)