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

111–115 of 115 posts

Re: A Better Git Flow

#111

Post by ninkendo »

digisign wrote: post #108
ninkendo wrote: post #97

Earlier quoted context omitted.

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.

Ok, that's one strategy. However, we put that information in our issue tracker, docs, and source code comments, where more people can reach them more easily. Commit msg is PROJ-1234, which gets automatically gets linked to issue with design and comment history and project/product folks can contribute.

I’m lost. What are you arguing at this point?

Re: A Better Git Flow

#112

Post by yencabulator »

cerved wrote: post #109
yencabulator wrote: post #107

Earlier quoted context omitted.

If every commit passes tests, tools like `git bisect` are much more useful.

how do you mean?

If you find a new bug, git bisect can very quickly find which commit introduced the bug, and understanding the origin makes fixing the bug easier. That mechanism does not work nearly as well if some commits are not in a usable state.

Re: A Better Git Flow

#113

Post by digisign »

ninkendo wrote: post #111
digisign wrote: post #108

Earlier quoted context omitted.

Ok, that's one strategy. However, we put that information in our issue tracker, docs, and source code comments, where more people can reach them more easily. Commit msg is PROJ-1234, which gets automatically gets linked to issue with design and comment history and project/product folks can contribute.

I’m lost. What are you arguing at this point?

The ancestor stated, all this futzing with commit history is a waste of time. I tend to agree.

Re: A Better Git Flow

#114

Post by _hao »

ninkendo wrote: post #110
_hao wrote: post #100

Earlier quoted context omitted.

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.

Sure, that’s exactly what I’m advocating for? I’m confused. You said it’s a waste of time to do this and to just squash when merging instead. I’m saying I’d rather squash first so that my PR looks clean and doesn’t contain my WIP commits. Then you respond saying “well you can just squash before your PR then”… are we going in circles?

Your use case is a bit different than what the article is arguing for. If you have a personal preference to have everything shown as a single commit in the PR by all means do things the way outlined above.

My original comment was targeting the two supposed problems that the article is framing and the supposed convoluted (and possibly dangerous) solution with git reset.

Re: A Better Git Flow

#115

Post by cerved »

yencabulator wrote: post #112
cerved wrote: post #109

Earlier quoted context omitted.

how do you mean?

If you find a new bug, git bisect can very quickly find which commit introduced the bug, and understanding the origin makes fixing the bug easier. That mechanism does not work nearly as well if some commits are not in a usable state.

but if that is the case why not just

  git bisect skip $(git merge-base main branch)
?

to me, squashing the tree to simplify an edge case seems needlessly radical

Post reply on HN