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

51–60 of 80 posts

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

#51

Post by ekipan »

minton wrote: post #18
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.

I've not tried jj yet so I can only speak to impressions, and those impressions appeal to me a lot. My understanding is that jj amends all the changes in _now_ so there's only one place where changes live: the commit graph. No index, no uncommitted worktree. Just commits. And then jj supposedly gives you a lot more freedom to move through and mutate the commit graph directly, rebasing dependent work for you automatically.

So instead of having to `git add -p` several times to pick apart changes from the worktree, the worktree always goes into the graph and you can `jj split` to pick them apart after.

    jj split # split latest commit into two
    jj edit @- # go back one
    jj describe # change message
    jj split # whoops, insert commit in the middle
    jj edit @+ # move forward again
    $EDITOR myfile # do some changes
    jj st # amend the changes and show status
    jj edit def # jump elsewhere in the graph
    jj squash # put two commits together and auto-rebase its descendants
    jj new abc # start working after latest
    # etc etc

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

#52

Post by 1718627440 »

Someone wrote: post #24

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.

You can run "git rebase last-tested-commit --exec='make check -j' to test a bunch of commits.

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

#54

Post by GuB-42 »

chrisweekly wrote: post #48
GuB-42 wrote: post #37

Earlier quoted context omitted.

For me the point of splitting commit is not for documentation (though it can be an added benefit). It is so that you can easily rollback a feature, or cherry pick, it also makes the use of blame and bisect more natural. Anyways, that's git, it gives you a lot of options, do what you want with them. If a big end-of-day commit is fine for you, great, but some people prefer to work differently. But that's not actually t…

Hmm, this idea of maintaining working copies that differ from upstream strikes me as fragile and cumbersome. For a solo project, sure, whatever works. But for larger projects, IMHO this workflow is an antipattern.

To be fair, yes, it is a bit fragile and cumbersome, though it works for me.

However, it doesn't makes "git -p" less useful when the idea is to separate what you want to publish and what you want to keep in your work zone, be is your working copy or a dev branch.

As always with git, it is not very opinionated, it lets users have their own opinions, and they do! Monorepos vs many repos, rebase vs merge, clean vs honest history,... it can do it all, and I don't think the debates will ever settle on what is an "antipattern" as I don't think there is a single "right" answer.

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

#55

Post by martinvonz »

y-curious wrote: post #46
t0mas88 wrote: post #36

Earlier quoted context omitted.

If you push a branch with many commits, does it run CI on each commit? In sequence or with some parallelism?

It runs on the last commit with the idea that it will all be squashed at merge. Are you worried about reverting some commits but not all?

That depends on the forge and the configuration of the forge. See the parent of the comment you replied to. Not everyone uses squash merge.

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

#56

Post by spider-mario »

kevinmchugh wrote: post #41

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)

> I don't know if I've ever committed a file unintentionally since adopting it.

I’ve had the opposite problem: forgetting to add new files.

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

No need for the rebase to be interactive:

    $ git commit --fixup=
    $ git rebase --autosquash

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

#58

Post by hbogert »

Someone wrote: post #24

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.

Do a git stash of working dir only after your git add -p. This was how the index/staging was meant to be used... I think

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

#59

Post by ekipan »

ekipan wrote: post #51
minton wrote: post #18

Earlier quoted context omitted.

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.

I've not tried jj yet so I can only speak to impressions, and those impressions appeal to me a lot. My understanding is that jj amends all the changes in _now_ so there's only one place where changes live: the commit graph. No index, no uncommitted worktree. Just commits. And then jj supposedly gives you a lot more freedom to move through and mutate the commit graph directly, rebasing dependent work for you automatic…

I confess I'm still pretty new to git. I haven't had a very long time to wed myself to git's index and its presence makes me do extra ceremony that I resent whenever I want to polish my graph for my personal projects.

The main difference, it seems, is workflow: git's "prepare then commit" vs jj's "commit then revise".

Currently I do make use of `git add -p` just like grandparent, but I also feel a psychological burden: I will often leave like 3 or 4 separate 2-line changes in the worktree because I don't wanna bother with the ceremony right now, but my perfectionism also resists me putting a lump commit. That's jj's main appeal to me. It amends my work in, then supposedly let's me sculpt it when I'm ready with less of that ceremony.

Post reply on HN