Hitting every branch on the way down • Hacker News Board

Re: Hitting every branch on the way down

#11

Post by btilly » Tue, Apr 30, 2024, 5:24 AM UTC

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!

One idiot with rebase destroys history with no trace. I worked with such an idiot in a parallel team. I can't say how many weeks of work randomly got destroyed by said idiot.

I hate rebase on shared code I don't care how clean jt looks. Don't mess with history.

Re: Hitting every branch on the way down

#12

Post by thaumasiotes » Tue, Apr 30, 2024, 5:30 AM UTC

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!

> I wont claim to understand C and the reason why is better than “”. I assume it is.

That one's obvious, you can type and you can't type “”.

Re: Hitting every branch on the way down

#13

Post by ephimetheus » Tue, Apr 30, 2024, 5:36 AM UTC

nvy wrote: post #4

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!

I believe that the semantics of vs "" is actually compiler-dependent but on every compiler that matters, #including with angle brackets is the semantic for "the system header" whereas using quotes gives preference to files in your local source tree. So for example if you #include then the compiler (actually the preprocessor, but whatever) looks in the system's standard location, whereas if you #include "foo" then it…

I think that’s just the ordering though. “” will also end up searching the system paths, it will just check the local paths first.

Re: Hitting every branch on the way down

#14

Post by Feathercrown » Tue, Apr 30, 2024, 5:43 AM UTC

btilly wrote: post #11

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!

One idiot with rebase destroys history with no trace. I worked with such an idiot in a parallel team. I can't say how many weeks of work randomly got destroyed by said idiot. I hate rebase on shared code I don't care how clean jt looks. Don't mess with history.

I wouldn't consider rebasing your own local commits on top of a more recent remote master to be messing with history in any meaningful way, and that's the most useful method of rebasing.

Re: Hitting every branch on the way down

#15

Post by pavon » Tue, Apr 30, 2024, 5:43 AM UTC

prerok wrote: post #5

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!

What I find strange is that traditionally included system header files and "" included local files. They used different include paths, so you could have a header file in your sources with the same name as the system header file and then could control whether you are including one or the other based on using or "". Anyway, I thought the distinction was lost in later compilers in favor of a single include path and then…

With both GCC and Visual C++, the “” form first searches local paths and then system paths, while the form only searches system paths. Guess some BSDs are stricter about local paths.

Re: Hitting every branch on the way down

#16

Post by lmm » Tue, Apr 30, 2024, 5:48 AM UTC

Feathercrown wrote: post #14

btilly wrote: post #11

Earlier quoted context omitted.

One idiot with rebase destroys history with no trace. I worked with such an idiot in a parallel team. I can't say how many weeks of work randomly got destroyed by said idiot. I hate rebase on shared code I don't care how clean jt looks. Don't mess with history.

I wouldn't consider rebasing your own local commits on top of a more recent remote master to be messing with history in any meaningful way, and that's the most useful method of rebasing.

Rebasing unpushed commits is ok. But I have yet to see a workflow that provides good enough guardrails to make it something you can do safely.

Re: Hitting every branch on the way down

#17

Post by doix » Tue, Apr 30, 2024, 5:54 AM UTC

btilly wrote: post #11

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!

One idiot with rebase destroys history with no trace. I worked with such an idiot in a parallel team. I can't say how many weeks of work randomly got destroyed by said idiot. I hate rebase on shared code I don't care how clean jt looks. Don't mess with history.

I really don't understand how you can lose weeks of work. The person that would have done the force push would have the original commit in their reflog. ORIG_HEAD would be set.

Everyone else that had a copy of the repo would have had a copy of the "lost" commits.

I really cannot imagine how many things would have to go wrong for weeks of work to be lost.

Re: Hitting every branch on the way down

#18

Post by saagarjha » Tue, Apr 30, 2024, 6:03 AM UTC

lmm wrote: post #16

Feathercrown wrote: post #14

Earlier quoted context omitted.

I wouldn't consider rebasing your own local commits on top of a more recent remote master to be messing with history in any meaningful way, and that's the most useful method of rebasing.

Rebasing unpushed commits is ok. But I have yet to see a workflow that provides good enough guardrails to make it something you can do safely.

Protect your main branch?

Re: Hitting every branch on the way down

#19

Post by jeffrallen » Tue, Apr 30, 2024, 6:06 AM UTC

This reminds me of a comment my new boss made, "you like learning on hard mode". He meant that instead of following doc to learn, I want to go find out how it works from first principles and then follow the docs, maybe improving them, based on what I saw from "beneath them" looking up.

Re: Hitting every branch on the way down

#20

Post by saghm » Tue, Apr 30, 2024, 6:14 AM UTC

> 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 this comment are:

v5.27.0-rc1 v3.27.0-rc1 v27.0-rc1 v27-dev v26.1 v5.26.1 v3.26.1 v26.1 v26.0 v5.26.0 v3.26.0

Does anyone here happen to know what's going on here? As best I can tell, they're simultaneously supporting 3 major versions while keeping their minor and patch versions in lockstep, and then having one major version be implicit?

I can almost imagine a scenario where they started out with just major and minor version and then realized they wanted to make breaking changes, which led them down the path of adding a third separate number to the versions, but if they already were going down the path of assuming "wider" versions are newer , why not just stop using version numbers with only major-minor and instead just add a 0 or 1 to the front of all of the continuations of that branch? Also, why synchronize every single minor and patch version between all three major versions? I can understand why it might be useful to continue providing support for multiple major versions at the same time, but I'd expect that _sometimes_ there might be a bug or something in only one of them, and pushing out a release of the other two that don't contain any changes would be pretty strange.

[0]: https://github.com/protocolbuffers/protobuf/tags