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

41–50 of 144 posts

Re: Hitting every branch on the way down

#41

Post by Gibbon1 »

datascienced wrote: post #2

I wont claim to understand C and the reason why is better than “”. I assume it is. But the fact that a merge can have arbitrary changes in it always bothers me! This is a case for rebase over merge if there are conflicts. You could have a merge of 2 empty repo parents where the result is the complete source of the latest version of Kubernetes!

> 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 lib.

Re: Hitting every branch on the way down

#42

Post by zokier »

I don't want to victim blame too much, but this line stood out to me

> There's no "body" to this commit. It's just a "Merge:" and two other commits

Commits are snapshots of repository state, and merges "obviously" have differences from its parents. So not having "body" for a commit is bit nonsensical in git (yes, technically you can make empty commits but that's a special case). These sort of things are where having good mental model of git is useful.

As I have my share of hairy merges, it is pretty intuitive that merge commits can, and in many cases need to, have changes that are not part of either parent.

Maybe something like pijul (/darcs) would handle things differently here, but I believe that merges are fundamentally difficult problem.

Re: Hitting every branch on the way down

#43

Post by rob74 »

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 increase test coverage? Guess we will never know, but still, open source is now a bit shittier because of it. Thanks, anonymous clueless developer!

    --  std::string left = "\"";
    --  std::string right = "\"";
    --  if (use_system_include) {
    --    left = "";
    --  }
    --  return left + name + right;
    ++  return absl::StrCat("\"", basename, "\"");

Re: Hitting every branch on the way down

#44

Post by saagarjha »

Gibbon1 wrote: post #41
datascienced wrote: post #2

I wont claim to understand C and the reason why is better than “”. I assume it is. But the fact that a merge can have arbitrary changes in it always bothers me! This is a case for rebase over merge if there are conflicts. You could have a merge of 2 empty repo parents where the result is the complete source of the latest version of Kubernetes!

> 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.

Re: Hitting every branch on the way down

#45

Post by baud147258 »

thriftwy wrote: post #36
bananskalhalk wrote: post #7

$ git show d85c9944c55fb38f4eae149979a0f680ea125ecb | wc -l 11067 $ From `man git-log`: "Note that unless one of --diff-merges variants (including short -m, -c, and --cc options) is explicitly given, merge commits will not show a diff, even if a diff format like --patch is selected, nor will they match search options like -S. The exception is when --first-parent is in use, in which case first-parent is the default fo…

And that's one of the reasons why I advocate against merges in the codebase on every project I work for and in every HN thread where the topic of merges is mentioned.

That might reveal the depths of my ignorance of Git, but how do you manage moving changes from one branch to the other if you don't use merge? Edit: continuing to read the discussion, it seems it's rebase? I have some reading to do

Re: Hitting every branch on the way down

#46

Post by BHSPitMonkey »

baud147258 wrote: post #45
thriftwy wrote: post #36

Earlier quoted context omitted.

And that's one of the reasons why I advocate against merges in the codebase on every project I work for and in every HN thread where the topic of merges is mentioned.

That might reveal the depths of my ignorance of Git, but how do you manage moving changes from one branch to the other if you don't use merge? Edit: continuing to read the discussion, it seems it's rebase? I have some reading to do

Or use squash merges.

Re: Hitting every branch on the way down

#47

Post by iainmerrick »

baud147258 wrote: post #45
thriftwy wrote: post #36

Earlier quoted context omitted.

And that's one of the reasons why I advocate against merges in the codebase on every project I work for and in every HN thread where the topic of merges is mentioned.

That might reveal the depths of my ignorance of Git, but how do you manage moving changes from one branch to the other if you don't use merge? Edit: continuing to read the discussion, it seems it's rebase? I have some reading to do

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 completely".

Re: Hitting every branch on the way down

#48

Post by pjc50 »

Reminds me of https://github.com/protocolbuffers/protobuf/issues/1491 , which has effectively been WONTFIX (why does github not have this useful distinction?) because Google are happy with how it works and it's really difficult to make this particular thing work with the (also broken) Python module import system.

Re: Hitting every branch on the way down

#49

Post by pjc50 »

zilti wrote: post #37
Groxx wrote: post #3

Earlier quoted context omitted.

Yep. Stuff like this is part of why I'm a rebaser. Rebase is simple . Always . The end result is obvious and clear and can only be interpreted in one way. Merge has lots of little sharp edges and surprises if you don't know every single tiniest detail. Almost nobody knows it in that level of detail, so it's a terrible choice for interacting with anyone else. If you're on your own, sure, do whatever - many things are…

"But it is littering the commit history with useless commits!" is what I always hear

Merge does that, yes, hence the preference for rebase flows.

(I'm surprised this got a downvote when that's how we got here: a situation in which a change was ""hidden"" in a merge commit that would have been explicit in a rebase workflow)

Re: Hitting every branch on the way down

#50

Post by maeln »

saghm wrote: post #20

> I told it to install "protobuf" since I use that library in my build tool. That actually installed "protobuf-24.4,1" which is some insane version number I'd never seen before. All of my other systems are all running 3.x.x type versions. I was curious about this, so I took a look at the list of protobuf releases[0] and they're...confusing, to say the least. Chronologically, the most recent tags at the time I write t…

It's because they changed the versioning format: https://github.com/protocolbuffers/protobuf/releases?page=5 / https://protobuf.dev/news/2022-05-06/

But I suppose old version still receive bugfixes.

Post reply on HN