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

71–80 of 80 posts

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

#71

Post by chrisweekly »

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

Earlier quoted context omitted.

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 hones…

Yeah, TIMTOWTDI, different strokes, etc... and I'm not claiming there's "one true way". I was just reacting (almost viscerally) to the idea of deliberately maintaining diffs in a stateful local env, which feels like it's begging for "works on my machine" issues. My instinct to avoid that, on principle, extends beyond project source code to "fiddly" local dev environments, seeking things like devcontainers, fully-reproducible builds for CI, etc.

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

#72

Post by lucasoshiro »

1718627440 wrote: post #65
lucasoshiro wrote: post #42

Earlier quoted context omitted.

> Maybe consider putting your energy into a good documentation inside the repository. Commit messages are documentation. If you have a good commit history you don't need write tons of documents explaining each decision. The history will contain everything that you need, including: when and who changed the code, what was the code change and why the code exists. You have a good interface for retrieving that documentati…

A surprisingly large amount of devs, do the work to record data into a VCS (probably because they are told to by colleagues or superiors), but never seem to use them. Then they tell you that generating proper commits isn't all that important. Well, that's because they never actually use the VCS. By my book, only generating commits isn't really using a VCS, that is the information generation part, you also need to do…

Agreed. If they don't care about the history, they don't need a vcs. There's no point in keeping a history if the history isn't helpful

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

#73

Post by 1718627440 »

lucasoshiro wrote: post #72
1718627440 wrote: post #65

Earlier quoted context omitted.

A surprisingly large amount of devs, do the work to record data into a VCS (probably because they are told to by colleagues or superiors), but never seem to use them. Then they tell you that generating proper commits isn't all that important. Well, that's because they never actually use the VCS. By my book, only generating commits isn't really using a VCS, that is the information generation part, you also need to do…

Agreed. If they don't care about the history, they don't need a vcs. There's no point in keeping a history if the history isn't helpful

I think they somewhat do care about the history, but only as a backup and list of older versions and as bunch of potential merge bases. But they do not care about the history as in the evolution and causality. It really depends on what you see as the history, so it is a manifestation of a somewhat philosophical problem.

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

#74

Post by 1718627440 »

ekipan wrote: post #59
ekipan wrote: post #51

Earlier quoted context omitted.

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 burde…

JJ and Git seem to have different philosophies, so they cater to different users. I want my VCS to do only things I tell it to, so recording things into the index on its own and automatically rebasing commits are not things I actually want.

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

Have you realized, that Git versions the index yet? It was written by a filesystem guy, who (I think) considers the filesystem to be a shared space, so Git doesn't consider the filesystem to be its playground. Think of "git add" less of preparing things for the next commit and more of telling git that it can consider some state to be part of its world model. Your repository does not consist of everything below a directory (it can actually span across multiple randomly located directories), it does consist of everything that was once added to the repository.

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

I do the latter just fine in Git, but yes "git add" is a fundamental part of my workflow. I often add some lines already to the index and start writing the commit message, then trying something again in the working directory and either throwing it away or also adding it, before I finally commit. To me the index is a feature.

> but my perfectionism also resists me putting a lump commit

Sounds like you will use a VCS correctly.

> I don't wanna bother with the ceremony right now

I don't know what exactly you consider to be the "ceremony", but I think nearly any git GUI/TUI will let you add lines by selecting with the cursor and pressing a key. The good ones also allow you to edit this. This also works in the opposite way: removing or editing specific lines from an already existing commit. In my experience carefully adding lines results in less mistakes than adding everything and then carefully removing lines, but YMMV.

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

#75

Post by 1718627440 »

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…

In addition to my other comment as you wrote you are not familiar with Git yet, some comparison to these commands. You can be in a commit in JJ, while in Git, you are always outside.

'jj edit' seems to correspond to 'git checkout', '@-' is '@~'. '@+' is not possible in Git, because a commit can have an arbitrary amount of children, Git might not even know about, not sure how JJ does this. @~5 is the 5th ancestor, @^5 is the fifth parent, @{5} is this ref five actions ago. This is the ref-log, which you can look at with 'git reflog' or 'git log --reflog'. 'master@{37.days.ago}' also works.

'jj split': use 'git commit --amend' and unselect changes or 'git reset --soft' to an older version, recommit the first part and then take the original commit on top. A git commit consists of a state, not of a diff so putting some commit on top of another that already contains part of the changes results in splitting the former.

'jj describe': 'git commit --amend'

'whoops, insert commit in the middle': just commit

'jj squash': either 'git reset --soft @~2' then 'git commit -c/C' or 'git reset @~' then 'git commit --amend' or 'git rebase' with squash or fixup. The later is possible from some other commit by using 'git commit --fixup' or even 'git absorb' (I think also exists in JJ).

Working in a detached state is fine, but you might want to add a ref (branch or tag, or something else) when you are finished, otherwise Git will eventually garbage-collect them (defaults to 4 weeks to 90 days depending on how you access the commit). You can push just fine to a remote, just specify the branch, i.e. 'git push origin @:branch'. You can also push to local branches to update them without checking them out with 'git push . @~7:feature/something'. Don't use pull, it is stupid, merge when you want to merge, rebase when you want to rebase, but don't do it implicitly as part of fetch.

Ask, if I glossed over something and shall elaborate.

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

#76

Post by t0mas88 »

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's the normal setup, but the parent comment made it sound like theirs would build every commit?

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

#78

Post by fixedprog »

fainpul wrote: post #62
kaelwd wrote: post #39

Earlier quoted context omitted.

You get light grey? The headings are #101828 and body text #364153 on #0a0a0a for me.

Light mode text: oklch(37.3% .034 259.733) Dark mode text: oklch(87.2% .01 258.338) Background in both modes: oklch(14.5% 0 0) See here: https://jsfiddle.net/kmtwf4g3/ I think the fuckup of the website author is that the background is black instead of white in light mode. Otherwise the text colors would be fine as they are. Probably vibe coded and never tested in light mode.

Not vibe-coded! I just didn't realize that the `prose` mode with Tailwind changes the default text colour set on other pages.

Lesson learned!

Post reply on HN