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

A Better Git Flow

render.com

Post reply on HN
Print view View original

91–100 of 115 posts

Re: A Better Git Flow

#91

Post by ninkendo »

digisign wrote: post #88
ninkendo wrote: post #66

Earlier quoted context omitted.

My point is that I don't want anyone to see my WIP commits in the first place. Squashing only in the end when merging to master means the code reviewers get to see my messy commit history, which is what I'm trying to avoid. (Yes, my commit history is that bad that it's embarrassing. But at least I commit early and often, which has saved my ass more times than I can count.)

Not in gitlab at least. Click on squash and you see nothing but the total of the branch difference, the merge req title, and a few lines of boilerplate it adds. About as easy as it gets. As titles are issue numbers changes are documented automatically.

I don’t want anybody to be able to see my WIP commits, even if it’s easy for them not to see them.

Yes, that probably is a “me” problem, and I’m too anxious about it for no reason, but that’s me. But if you saw my local scratch branches you’d probably understand.

(My wip commits occasionally bitch about coworkers, for example. Or they just contain a bit too much profanity for a professional environment. Or there’s just 50 worthless “WIP” commits with no other description. You’d never know any of this from my PRs.)

Re: A Better Git Flow

#92

Post by cerved »

karl42 wrote: post #64
cerved wrote: post #56

Earlier quoted context omitted.

Fix-ups are nice. I developed a script that takes the all staged content and breaks them up into separate fix-ups that fixup the last commit that changed those lines. I find it pretty handy

That sounds much like git absorb. See https://github.com/tummychow/git-absorb

thanks I didn't know about that

maybe, but it's probably much simpler. It's just a small bash script that runs git blame twice for each line in the index and creates a fixup per commit found

Re: A Better Git Flow

#93

Post by cerved »

okl wrote: post #61
cerved wrote: post #50

Earlier quoted context omitted.

what's the advantage over partial?

Give it a try and compare. tig lets you either stage hunks ('u') or lines ('1'). You can also adjust the context ('[', ']') and split chunks ('\') and revert chunks ('!') all from the same view.

I will thanks but I must say in mostly very happy with --partial, except stash which is slow, or when there are 20+ hunks

Re: A Better Git Flow

#94

Post by cerved »

ninkendo wrote: post #57
cerved wrote: post #53

Earlier quoted context omitted.

the only gotcha with rebase is that it cherry picks commits and so if you do it willy nilly then you can end up introducing changes where you don't expect them and reverting reverts it's more complicated but vastly more powerful than reset

My problem with rebasing is that the vast majority of my commits are garbage "WIP" commits, and I want to squash them away anyway. Squash-rebasing on top of main makes git replay all of those dumb commits, just to squash them, and I have to fix merge conflicts individually, for every commit I don't even care about, before it's done. I'd much rather soft-reset to the merge-base, make one clean commit, then rebase that…

I do to sometimes but I find it to be a poor habit and something I try and avoid or rebase away

Re: A Better Git Flow

#95

Post by digisign »

ninkendo wrote: post #91
digisign wrote: post #88

Earlier quoted context omitted.

Not in gitlab at least. Click on squash and you see nothing but the total of the branch difference, the merge req title, and a few lines of boilerplate it adds. About as easy as it gets. As titles are issue numbers changes are documented automatically.

I don’t want anybody to be able to see my WIP commits, even if it’s easy for them not to see them. Yes, that probably is a “me” problem, and I’m too anxious about it for no reason, but that’s me. But if you saw my local scratch branches you’d probably understand. (My wip commits occasionally bitch about coworkers, for example. Or they just contain a bit too much profanity for a professional environment. Or there’s ju…

Recording sensitive information then relying on your perfect performance to remove it is flawed opsec. Not to mention a waste of time, as our great ancestor mentions.

Re: A Better Git Flow

#96

Post by rpowers »

_hao wrote: post #6

What a waste of time and effort. Squash when merging to master and be done with it. Every PR/commit merged to master should be a clean logical unit. That means not fixing a bug in a branch where I'm doing something else. Those will be two separate PR's. The second problem shouldn't exist IMO.

Yeah I'm also confused why making multiple unrelated changes is celebrated with a special gitflow. Two changes == Two PRs.

Re: A Better Git Flow

#97

Post by ninkendo »

digisign wrote: post #95
ninkendo wrote: post #91

Earlier quoted context omitted.

I don’t want anybody to be able to see my WIP commits, even if it’s easy for them not to see them. Yes, that probably is a “me” problem, and I’m too anxious about it for no reason, but that’s me. But if you saw my local scratch branches you’d probably understand. (My wip commits occasionally bitch about coworkers, for example. Or they just contain a bit too much profanity for a professional environment. Or there’s ju…

Recording sensitive information then relying on your perfect performance to remove it is flawed opsec. Not to mention a waste of time, as our great ancestor mentions.

It’s not a career ending thing if somebody saw my commit history. It’s just mildly embarrassing. It’s not a waste of time either… time spent crafting a final commit from the whole change, writing a descriptive commit message, and documenting everything well helps people review it, and that’s time well spent.

Re: A Better Git Flow

#99

Post by _hao »

Double_a_92 wrote: post #75
_hao wrote: post #6

What a waste of time and effort. Squash when merging to master and be done with it. Every PR/commit merged to master should be a clean logical unit. That means not fixing a bug in a branch where I'm doing something else. Those will be two separate PR's. The second problem shouldn't exist IMO.

This does not work well if you have long-lived branches (i.e. weeks) for more substantial features. Completely squashing it would lose all the granular commits and especially their commmit messages, which might be useful for debugging later on.

You are implying the original branch holding that history will be deleted when squashed into a single commit for a PR. That's not the case (granted, that's based on settings on GitHub, Azure DevOps whatever you're using, but the option is there) because in the PR you still see which branch the changes come from. If you're not deleting the branches you're good. Even if you delete the branch when merging I think most PR views nowadays will keep that info (the commits) in perpetuity. Again, I don't think this is a problem.

Re: A Better Git Flow

#100

Post by _hao »

ninkendo wrote: post #66
kristaps wrote: post #63

Earlier quoted context omitted.

It's true that messy commits happen, that's why squash is there. Nothing forces you to keep the messy commit messages either - keep the short commit message and make sure it's good, then delete the combined individual commit messages from the long message field, done.

My point is that I don't want anyone to see my WIP commits in the first place. Squashing only in the end when merging to master means the code reviewers get to see my messy commit history, which is what I'm trying to avoid. (Yes, my commit history is that bad that it's embarrassing. But at least I commit early and often, which has saved my ass more times than I can count.)

Why not create a new branch (let's call it B) from your messy branch (call it A) and squash everything in B before raising a PR from B -> master

That will solve your problems if you're the messy type.

Post reply on HN