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

Using Git add -p for fun (and profit)

techne98.com

Post reply on HN
Print view View original

11–20 of 80 posts

Re: Using Git add -p for fun (and profit)

#11

Post by agoose77 »

mvanbaak wrote: post #9
ktpsns wrote: post #5

What's wrong with a big end of day commit? Sure, a well crafted git history can be very valuable. But then comes somebody and decides to just flush your well curated history down the toilet (=delete it and start somewhere else from scratch) and then all the valuable metadata stored in the history is lost. Maybe consider putting your energy into a good documentation inside the repository. I would love to have more pro…

if commit messages are meaningful and the commits are well crafted (with the help of git add -p for example) this documentation can be generated from the metadata ;P Also, big end of day commits normally cover multiple different fixes. Which is, I hope you can understand, not very nice to have in one big commit. If someone else decides your implementation of something is not good enough, and they manage to get enough…

Also, rebasing is a lot easier when you have small commits, rather than a mega conflict.

Re: Using Git add -p for fun (and profit)

#12

Post by pseufaux »

This is one place jj really shines. Using jj new to quickly switch to a new change makes it easier to not drop flow but still break up work. You can come back later and add descriptions or reorder and squash. That way, you don't get into as many situations where splitting a commit is necessary. For those that remain, jj split works well.

Re: Using Git add -p for fun (and profit)

#14

Post by a13o »

ktpsns wrote: post #5

What's wrong with a big end of day commit? Sure, a well crafted git history can be very valuable. But then comes somebody and decides to just flush your well curated history down the toilet (=delete it and start somewhere else from scratch) and then all the valuable metadata stored in the history is lost. Maybe consider putting your energy into a good documentation inside the repository. I would love to have more pro…

Atomic commits compose easier. In case you want to pull a few out to ship as their own topic. Or separate out the noisy changes so rebases are quicker. Separate out the machine-generated commit so you can drop it and regenerate it on top of whatever.

My commit messages are pretty basic “verbed foo” notes to myself, and I’m going to squash merge them to mainline anyway. The atomic commits, sometimes aided by git add -p, are to keep me nimble in an active codebase.

Re: Using Git add -p for fun (and profit)

#15

Post by jraph »

ktpsns wrote: post #5

What's wrong with a big end of day commit? Sure, a well crafted git history can be very valuable. But then comes somebody and decides to just flush your well curated history down the toilet (=delete it and start somewhere else from scratch) and then all the valuable metadata stored in the history is lost. Maybe consider putting your energy into a good documentation inside the repository. I would love to have more pro…

> But then comes somebody and decides to just flush your well curated history down the toilet (=delete it and start somewhere else from scratch) and then all the valuable metadata stored in the history is lost.

How does this happen? I haven't run into this.

> Maybe consider putting your energy into a good documentation inside the repository

I'd say both are valuable.

I use git log and git blame to try to understand how a piece of code came to be. This has saved me a few times.

Recently, I was about to replace something strange to something way more obvious to fix a rendering issue (like, in some HTML, an SVG file was displayed by pasting its content into the HTML directly, and I was about to use an img tag to display it instead), but the git log told me that previously, the SVG was indeed displayed using an img tag and the change was made to fix the issue that the links in the SVG were not working. I would have inadvertently reverted a fix and caused a regression.

I would have missed the reason a code was like this with a big "work" end of the day commit.

It would have been better if the person had commented their change with something like "I know, looks weird, but we need this for the SVG to be interactive" (and I told them btw), but it's easy to not notice a situation where a comment is warranted. When you've spent a couple of hours in some code, your change can end up feeling obvious to you.

The code history is one of the strategies to understand the code, and meaningful commits help with this.

Re: Using Git add -p for fun (and profit)

#17

Post by ViVr »

ktpsns wrote: post #5

What's wrong with a big end of day commit? Sure, a well crafted git history can be very valuable. But then comes somebody and decides to just flush your well curated history down the toilet (=delete it and start somewhere else from scratch) and then all the valuable metadata stored in the history is lost. Maybe consider putting your energy into a good documentation inside the repository. I would love to have more pro…

When working on a feature branch it can be useful to break up your changes into logical commits. This gives you the flexibility to roll back to an earlier iteration when still working on the feature if needed.

One of my git habits is to git reset the entire feature branch just before opening a PR, then rebuild it with carefully crafted commits, where i try to make each commit one "step" towards building the feature. This forces me to review every change one last time and then the person doing code review can also follow this progression.

These benefits hold even if the branch ultimately gets squashed when merging into main/master. I also found that even if you squash when merging you can still browse back to the PR in your git repository web UI and still see the full commit history there.

Re: Using Git add -p for fun (and profit)

#18

Post by minton »

pseufaux wrote: post #12

This is one place jj really shines. Using jj new to quickly switch to a new change makes it easier to not drop flow but still break up work. You can come back later and add descriptions or reorder and squash. That way, you don't get into as many situations where splitting a commit is necessary. For those that remain, jj split works well.

I’ve looked at jj, but couldn’t make sense of the proposed benefits. I always stage individual files and never the entire working directory, so I’m confused how it improves that over git.

Re: Using Git add -p for fun (and profit)

#19

Post by rogerbinns »

howToTestFE wrote: post #2

I find the jetbrains IDEs (like Webstorm) has the best UI interface for this. Selectively commit specific lines from your changes.

Another excellent GUI is gitg. You can select specific lines for staging, but also for discarding. The latter is especially useful for temporary debug only changes that you want to throw away.
Post reply on HN