undefined | Better HN

0 pointschrisweekly3mo ago0 comments

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.

0 comments

GuB-423mo ago

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.

chrisweeklyOP3mo ago

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.

j / k navigate · click thread line to collapse

0 comments

GuB-423mo ago

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.

chrisweeklyOP3mo ago

j / k navigate · click thread line to collapse