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

Extremely Linear Git History

westling.dev

Post reply on HN
Print view View original

201–210 of 366 posts

Re: Extremely Linear Git History

#201

Post by Sohcahtoa82 »

jonstewart wrote: post #143
sshine wrote: post #92

Earlier quoted context omitted.

> If you committed something that broke unit tests your colleagues would pass you a really ugly plush animal of shame that would sit on your desk until the next coworker broke the build. We did have an ugly plush animal, but it served more obscure purposes. For blame of broken builds, we had an info screen that counted the number of times a build had passed, and displayed below the name of the person who last broke i…

I once interviewed a junior-ish developer who told me that his then-current team had a dunce cap to be worn by whomever broke the build. I copied it immediately. There was no toxicity, it was a good laugh, and as manager I wore it more than once being a bit too liberal with my commits. On another team I was on, in 2002 using CVS, we had an upside-down solo cup as a base for a small plastic pirate flag. If you were re…

> The pull request model is fine for open source development, but it’s been a move backwards for internal development

The more paranoid would claim that requiring PRs that then require approvals prevents a malicious engineer from adding an obvious back door to the code.

You would hope you can trust your co-workers, but sometimes a hack is an inside job.

Re: Extremely Linear Git History

#202

Post by HWR_14 »

mamcx wrote: post #130
simiones wrote: post #83

Earlier quoted context omitted.

Unfortunately, git rebase has a very very annoying limitation that git merge doesn't. If you have a branch with, say, masterX + 10 commits, and commit 1 from your branch is in conflict with masterX+1, then when you rebase your branch onto masterX+1, you will have to resolve the conflict 10 times (assuming all 10 commits happen in the same area that had the original conflict). If instead you merge masterX+1 onto your…

I was converted to rebase by my current team, and this hit every time. I wish it works like merge, or exist a way to merge, resolve conflict, rebase?

Can I asked how they converted you (or do you mean by dictate, as opposed to becoming convinced it was better)? I find myself loving merges and never using rebases. It's not that I cannot describe technically what's happening, but I just don't understand the love.

Re: Extremely Linear Git History

#203

Post by wkdneidbwf »

thewebcount wrote: post #174
titzer wrote: post #108

Earlier quoted context omitted.

Commit queues are so far superior to shaming broken builds that I think it's only nostalgia that makes you miss it.

Absolutely. In my experience, it’s only “not toxic” to a few people, and for most others it is toxic, but the people who like it won’t ever be able to see that.

exactly. even if the current team is cool with it, team+1 may not be, and now they're in a position that feels shitty to them. it's good 'ole boys club shit.

people brag about their dunce caps, "john's fault" commit messages from managers, and other forms of public shame as a badge of honor when it would be so much more interesting to here about how they fixed their broken processes that led to the problems in the first place.

"oops, a developer fucked up the prod db" says more about the org and its processes than it does about the developer.

Re: Extremely Linear Git History

#204

Post by jonstewart »

jasmer wrote: post #155
jonstewart wrote: post #150

Earlier quoted context omitted.

I don’t want to make up a good name for every commit. Good comments are hard enough. A SHA-1 might not look friendly to a dev who doesn’t understand it, but as someone who works with hash values all the time, having my repo be a Merkle tree gives me a warm fuzzy.

You wouldn't 'make one up' there would be an automatic variation of Semantic Versioning, or something actually useful. Your 'warm and fuzzy' comes at the cost of confusion (even to yourself), not having any clue what the information really means. It's not even clear that it's a commit, it could be anything. This posture is exactly what I'm complaining about: it's objectively bad design engineering, embraced as though…

Git has problems: stipulated. Improvements in design are possible: also stipulated.

But, your reply is annoying in opining about my mental state and preferences. How am I confused by the SHA-1 commits, exactly? And how am I unclear that I’m looking at commits when I issue a “git log”?

Re: Extremely Linear Git History

#205

Post by tcoff91 »

thunky wrote: post #198
geon wrote: post #190

Earlier quoted context omitted.

A long lived feature branch is not a problem if you rebase it to master often. Move all refactoring to the beginning of the branch and merge them to master if they become too many.

> A long lived feature branch is not a problem if you rebase it to master often. Yes but if it's a shared branch then you may have problems with this. The safer way is to merge from master into the branch but nobody wants to do that because it's ugly.

For long-lived feature branches that are the target of multiple smaller PRs, history should never be rewritten. I call these branches integration branches. I agree with you wholeheartedly that master should be merged into the branch. It's also so much easier to resolve merge conflicts all at once in the merge commit rather than iteratively for each commit. Also, the information on how merge conflicts are resolved is then preserved in the merge commit. It's critical however that when you merge the branch back into master, you use --no-ff. It gets really confusing when you fast forward master to the feature branch.

The solution for it being ugly is to look at main/master's history with the --first-parent option. This lets you cut through the noise and just see the true history of the main branch. Without --first-parent, you see a bunch of commits in the log that master was never actually pointing at. This is why it's critical that you use --no-ff when merging these 'integration' branches as I call them. It's important that the integration branch is the second parent of master.

Re: Extremely Linear Git History

#206

Post by jonstewart »

Sohcahtoa82 wrote: post #201
jonstewart wrote: post #143

Earlier quoted context omitted.

I once interviewed a junior-ish developer who told me that his then-current team had a dunce cap to be worn by whomever broke the build. I copied it immediately. There was no toxicity, it was a good laugh, and as manager I wore it more than once being a bit too liberal with my commits. On another team I was on, in 2002 using CVS, we had an upside-down solo cup as a base for a small plastic pirate flag. If you were re…

> The pull request model is fine for open source development, but it’s been a move backwards for internal development The more paranoid would claim that requiring PRs that then require approvals prevents a malicious engineer from adding an obvious back door to the code. You would hope you can trust your co-workers, but sometimes a hack is an inside job.

There are all sorts of workflows that can be arranged to prevent that while still having optimistic continuous integration on trunk.

Re: Extremely Linear Git History

#207

Post by tcoff91 »

blux wrote: post #153

I fail to see the point of this, in fact, I think this is a fundamentally flawed approach to dealing with your revision history. The problem is that rebasing commits has the potential of screwing up the integrity of your commit history. How are you going to deal with non-trivial feature branches that need to be integrated into master? Squash them and commit? Good luck when you need to git bisect an issue. Or rebase a…

If people knew about --first-parent everyone could stop complaining about merge commits in the history.

Re: Extremely Linear Git History

#208

Post by Izkata »

simiones wrote: post #173
quadhome wrote: post #95

Earlier quoted context omitted.

man git-rerere

It often amuses me that some people will say "git is actually easy, you just need to know git commit, git pull, git push, and git branch", but when you go into the details, you find out you have to learn a hundred other rarer tools to actually fix the 5% or 1% use cases that everyone eventually hits. For what it's worth, I had heard of git rerere before, and have looked at the man page, but haven't understood how it'…

When you hit a merge conflict, rerere (re)members how you (re)solved it and (re)applies the same fix when the same conflict happens again. But using it can create a new problem/annoyance: If you make a mistake with the initial resolution, and revert the merge/rebase to try again, it'll remember the wrong one next time. So you have find and tell it to forget that resolution.

Re: Extremely Linear Git History

#209

Post by Sohcahtoa82 »

voxl wrote: post #192
rfrey wrote: post #152

Earlier quoted context omitted.

It's not toxic because every single developer knows that it could be them next time around.

It is literally the definition of toxic. It is the antithesis of making it okay to fail, having the entire team to take responsibility. Instead individual mistakes are highlighted and publicly shamed. How can you possibly not think this is toxic?

Think of it more as a fun and gentle ribbing than public shaming.
Post reply on HN