Using Git add -p for fun (and profit) (techne98.com)

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

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 projects with documentations which cover the timeline and ideas during development, instead of having to extract these information from metadata - which is what commit messages are, in the end.

I'm a big fan of how tig TUI makes this, and other git actions, very simple https://jonas.github.io/tig/

FYI: your website is barely readble with light mode.

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.

Wait till you've start using `git commit -p -m "my commit"`.

I love Zed editor's git UI for this. If you click on the left gutter of a hunk, it opens a little interface in the top right corner that lets you either Stage or Restore that hunk.

A disadvantage of git add -p is that it allows you to create a commit that never existed on the development system, and, hence, cannot have been tested.

How do people handle that? One way would be to follow it up with git stash, running tests, and, if necessary, git amend, but that can get cumbersome soon.

If you liked this, you're going to love

    git commit --verbose --patch

I strictly use git add -p.

for one, it lets me create small patches of related stuff. There's nothing wrong with major patchsets in general but it makes it harder to cherry-pick little fixes to old stable branches for example

two, I notice other developers making me do the work for them because crap sneaks into their commits, like debugging statements or accidentally removed hunks. Instead I have to do "git add -p" when reviewing their commit.

Essentially, it's a first pass staging area you can review what you did. beautiful.

Is there any tool that allows you to pass the line numbers that you want to stage as arguments to the command, instead of having to do it interactively?

I've been using this UI git diff add script for years: https://github.com/ismell/diffadd I think it works better then the TUI. Surprised something like it hasn't landed in upstream git.

This is the second link from the HN start page that doesn't load due to La Liga censoring in Spain.

I've been using lazygit [https://github.com/jesseduffield/lazygit] which is a friendly TUI that makes selecting which lines to commit relatively painless. As a heavy user of hunk-by-hunk or line-by-line commits, I used to use tortoisehg, but on my current distro its showing some bitrot, so I decided to try something else.

I almost exclusively use add -p. It's another moment to review my changes and it saves me from having to type out the names of the files I've changed. I don't know if I've ever committed a file unintentionally since adopting it.

I like it especially in concert with git commit --amend, which lets me tack my newest changes onto the previous commit. (Though an interactive rebase with fixup is even better)

vim-fugitive for Vim/Neovim is even better as it allows you to do per line stages, not just per hunk.

There are many other plugins for vim and emacs (e.g. magit) that enhance one’s git workflow.

My two favourite bits of git add -p that aren't mentioned here:

the / (search) command to search unstaged hunks for a specific keyword rather than having to jump through all the individual changes you've made when there's lots.

and the e (edit) command to manually split out two changes that end up in one hunk that I'd rather have in individual commits.

This has been the default for us using magit for years.

I find `jj commit -i` much easier.

Lol or they could use VSCode's integrated source control and stage stuff manually that way. Both are better than bare `git add -p` in my opinion.

How can a programmer write -P in the titles when the flag is -p?

Great tip, I have git add -p aliased to "gap" because I use it so often