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

Hitting every branch on the way down

rachelbythebay.com

Post reply on HN
Print view View original

111–120 of 144 posts

Re: Hitting every branch on the way down

#111

Post by hoseja »

RHSeeger wrote: post #105
plq wrote: post #90

Earlier quoted context omitted.

In the chromium repository, the use of angle brackets in #include statements is banned -- they only use double quotes. They also don't use any system headers per se since their flavor of clang comes with their flavor of libcpp vendored in. So if the chromium repo is representative of the state of C++ in rest of Google, they ditched it silently like this probably because it's so natural to them :)

So, instead of using > means system headers and "" means project headers (my naive understanding of the difference) they just convert everything to a project header? That seems bonkers to me. It is intentionally removing useful information.

Hierarchy is problematic.

Re: Hitting every branch on the way down

#113

Post by Sharlin »

xorcist wrote: post #79
rob74 wrote: post #43

So, someone at some point in some commit that we will never see because it got squashed with other commits thought it would be cooler to use absl::StrCat() instead of the "+" operator, and in the process of doing that, they went "what's this useless code using angled brackets instead of quotes?! It works with quotes too, let's delete it!". Or maybe that part was difficult to test, so they simply deleted it to increas…

Why do you think it was squashed? This article is clear about this being a merge commit. This person got a merge conflict and decided that this was the best way to fix it. It probably worked on their machine. Perhaps not necessarily the optimal fix when you have thousands of users depending on this code, but what do I know?

But according to the article, both of the parents contained the same old code. Could be that it was just collateral damage in a larger conflict, but still it seems that someone used the merge commit to make an off-topic, ad-hoc change that was not only superfluous but code-breaking.

Re: Hitting every branch on the way down

#114

Post by rileymat2 »

RHSeeger wrote: post #105
plq wrote: post #90

Earlier quoted context omitted.

In the chromium repository, the use of angle brackets in #include statements is banned -- they only use double quotes. They also don't use any system headers per se since their flavor of clang comes with their flavor of libcpp vendored in. So if the chromium repo is representative of the state of C++ in rest of Google, they ditched it silently like this probably because it's so natural to them :)

So, instead of using > means system headers and "" means project headers (my naive understanding of the difference) they just convert everything to a project header? That seems bonkers to me. It is intentionally removing useful information.

The main difference is how the search for the file works. “” prefers local directory before the search path, goes to the search path first.

Re: Hitting every branch on the way down

#115

Post by plq »

RHSeeger wrote: post #105
plq wrote: post #90

Earlier quoted context omitted.

In the chromium repository, the use of angle brackets in #include statements is banned -- they only use double quotes. They also don't use any system headers per se since their flavor of clang comes with their flavor of libcpp vendored in. So if the chromium repo is representative of the state of C++ in rest of Google, they ditched it silently like this probably because it's so natural to them :)

So, instead of using > means system headers and "" means project headers (my naive understanding of the difference) they just convert everything to a project header? That seems bonkers to me. It is intentionally removing useful information.

First, here's the actual guide: https://google.github.io/styleguide/cppguide.html#Names_and_... . Of course they still have to use stuff like #include but it's very very limited.

They also are not removing any info -- most of it IS project headers. To me that's the actual bonkers bit :)

With GCC/Clang, headers found in paths passed with -isystem are headers that are immune to compiler arguments like -Werror because they are, by definition, out of your control. In Google's case, ALL code is already checked in the project repo, including language stdlib. So none of them are system headers "per se".

Re: Hitting every branch on the way down

#116

Post by hoseja »

saagarjha wrote: post #44
Gibbon1 wrote: post #41

Earlier quoted context omitted.

> But the fact that a merge can have arbitrary changes in it always bothers me! After that xy thing where they were trying to install a back door having changes that are hidden like this is a big red flag. In fact changing include to include "something.h" with a hidden commit like this isn't a red flag it's a big rotating alarm with a siren. Someones trying set things up to include malicious code via a faked system l…

Sadly, not all of us can live in the tech equivalent of Bond films. There is only so many xz backdoors to go around.

There could be thousands of similar manchurian developers right now and it wouldn't even be a significant effort.

Re: Hitting every branch on the way down

#117

Post by msteffen »

RHSeeger wrote: post #102
iainmerrick wrote: post #47

Earlier quoted context omitted.

When people talk about avoiding merges, I think they mean this: https://trunkbaseddevelopment.com The approach described on that site doesn't strictly rule out "git merge", but it emphasises short-lived branches and unidirectional commit flow. If you do things that way you find you just don't really need merges. The next step is to think "merges are rarely useful and sometimes dangerous, so let's just avoid them comp…

> Streaming small commits straight into the trunk Gotta say, I find that horrifying. What about peer reviews? What about breaking up a change into smaller commits, none of which make sense until they're all together (changing the signature of a method, then changing the places that call that method, etc)? It's worth noting that is mentions that work on a branch and the use of PRs are acceptable, but... the two statem…

I can’t find the quoted text in the parent post or article, but as someone who’s fought the short-lived branches crusade in the past (in favor of it) I’ll do my best to answer the criticism you raise :-)

> What about breaking up a change into smaller commits, none of which make sense until they're all together (changing the signature of a method, then changing the places that call that method, etc)?

The general-form solution to this is to make a three-part change: 1. add the new code, 2. migrate all the callers, 3. delete the old code in three separate PRs (or more, if migrating the callers takes several PRs, or some of the old code can be deleted earlier than the rest). I believe arbitrarily large changes can be made this way, and as your origination grows, eventually all large changes _have_ to be made this way.

Isn’t that a lot of extra work? IME it’s a lot less work (and risk!) than resolving a massive merge conflict.

The problems with long-lived branches all derive from the basic problem that eventually the complexity of maintaining two parallel implementations affects the work of everyone at the company.

New person joins before `Big_Refactoring` is merged? You’re either onboarding them twice into two branches, or they’re getting nothing done while they wait for the merge so they don’t have to learn a bunch of code that’s going away soon anyway.

Someone else wants to make a significant change? They either carefully patch each PR into both branches, or they decide “screw it” and do all their work in `Big_Refactoring` anyway, diverging the branches _even more_ and creating more risk in the ultimate merge and more of an incentive for others to start developing in `Big_Refactoring` and make the problem even worse. Soon the feature branch is a de facto main with failing tests while there’s incredible pressure to just ram the merge through so all these changes can go out.

The only way to make it work is to demand that only one person develop in `Big_Refactoring` and everybody else manually cherry-pick their changes into both branches (which quickly just means implementing them twice). IME everyone finds this so annoying that small branches, feature flags, and three-part changes (which makes code sharing between the old and new implementations much easier) become broadly preferred anyway.

As far as PRs, I can’t speak to the linked article, but everywhere I’ve worked that implemented short-lived branches still did PR review. But the PRs had to be small and quick to review (which IME actually helps catch bugs too)

Re: Hitting every branch on the way down

#118

Post by vundercind »

pjc50 wrote: post #101
vundercind wrote: post #99

Earlier quoted context omitted.

This is a great way to get me to clutter the shared repo with throwaway branches that I’ll later replace (deleting the old one—if you let me).

This is fine! This is a normal part of several popular git workflows. After all, a branch is just a pointer to a commit. (Our workplace has a mix of github flow, which is one branch per PR: https://docs.github.com/en/get-started/using-github/github-f... ; Atlassian Gitflow https://www.atlassian.com/git/tutorials/comparing-workflows/... ; and the completely different Gerrit flow which ends up very rebase and amend hea…

I thought you meant blocking all force-push. Shared branches should absolutely be protected (with an “in case of emergency, break glass” option)

Re: Hitting every branch on the way down

#119

Post by xorcist »

CoastalCoder wrote: post #89
xorcist wrote: post #80

Earlier quoted context omitted.

Commits are for saving your current work. Commit early, commit often. Just clean them up when you're done! Don't push half-baked work on other people! You waste their compute cycles needlessly, from now until the end of time.

I sometimes wish git supported hierarchical commits. I.e., git can retain two representations of a sequence of commits: the original sequence, and also a larger commit that (a) produces the exact same code change as the sequence, and (b) has its own commit message.

I have entertained similar thoughts, but then on the other hand people already, and with some righteousness, criticize git for being too complex. It also requires careful assessment where the wormhole ends, how many levels of grouped commits should exist.

Then I remember that I have enough trouble getting a few dozen people together to write well formed and understandable commit messages for one level of commit messages alone. This scheme would require people to extend more energy on constructing commits which is at best something very few care about.

Then there are tickets and other corresponding information, but they could rot for all I care, as they so often do, unless a decent commit log is in place.

Re: Hitting every branch on the way down

#120

Post by kidintech »

Piper and Protobufs lmao. Based on personal experience, the two services are best used as litmus tests of a person’s character — the most insufferable googlers I've met are fans of both. Any other usage of either generally results in undescribable frustration.
Post reply on HN