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

121–130 of 144 posts

Re: Hitting every branch on the way down

#121

Post by BobbyTables2 »

ori_b wrote: post #106
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…

I think protobuf might just be a performance art piece, exploring the question of how much complexity it's possible to insert into a simple concept.

Indeed. Having used it and examined the resulting binary formats it uses, I don’t get it. Google makes some nice things, but protobuf isn’t one of them.

IIRC (5 yes ago), it was somewhat self describing with respect to struct offsets but had no (data format) versioning or type information. Never understood that design choice, even in mixed endian+architecture environments.

Ends up being horribly inefficient for small/one-time instances, and not all that great for client/server use.

We were looking at it to get away from C structs and handmade serialization — only to unexpectedly realize that our methods were still better. (We genuinely did not want this outcome!). JSON/yaml were not options for other reasons.

Protobuf is the modern realization of “the king has no clothes”.

Re: Hitting every branch on the way down

#122

Post by BobbyTables2 »

maeln wrote: post #50
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.

If only they had a language agnostic way of encoding version information…

Perhaps someone wrote a library for that…

Re: Hitting every branch on the way down

#123

Post by twic »

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.

FWIW, Mercurial has this, and calls it changeset evolution:

https://www.mercurial-scm.org/doc/evolution/

Re: Hitting every branch on the way down

#124

Post by btilly »

doix wrote: post #17
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 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.

What went wrong was multiple teams on unsynchronized 2 week schedules, and a culture that said that we had to accept the force push when other teams released.

So we released at the end of our cycle. It gets used for, if a vague memory serves, end of months billing. Meanwhile someone on another team "merged" our code, and actually randomly dropped a big chunk of our work. A week later they release. Some (but not all) of our features disappear. We pull that and don't notice because we're on a new sprint. Wait until the end of the month, users try to do billing. "Hey, why did you take away those features you built for us a month ago?" "What, we never...?"

We had no clue what happened.

This got to repeat a couple of times before we figured out what must be happening. We made changes to the release process so we could track what was actually released each time, with its history. We tracked down who we thought was making the mistake, but didn't have enough evidence to prove it to his manager. That didn't stop the idiot from making the mistake, but it did streamline the process of recovering it. Meaning we had the version with our feature, we had current code, and "just" had to sort out conflicts rather than rewrite from scratch.

Now that you've heard the story, can you see how weeks of work could be lost before we figured it out? And can you understand how we could have lost history?

This was a decade ago. At my next job we had more competent people. But there we had a huge debates between rebase and merge people. There are arguments on both sides. My conclusion was that about 90% of the time, rebase makes things simpler and easier. But that remaining 10% of the time makes the 90% not worth it.

Just learn how to merge properly.

Re: Hitting every branch on the way down

#125

Post by saagarjha »

hoseja wrote: post #116
saagarjha wrote: post #44

Earlier quoted context omitted.

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.

Until they're activated how are you going to know?

Re: Hitting every branch on the way down

#126

Post by Izkata »

wdfx wrote: post #55
skywal_l wrote: post #39

Earlier quoted context omitted.

And the best answer is: "Why do you do useless commits?". With `git amend` and `git fixup` you can arrange your commits to be clean, properly documented and self explanatory (and maybe atomic but that's a little harder). It takes a little time but it is hugely beneficial to code reviews and bug investigation.

Some people however see using features like amend, squash, and force push as potentially destructive actions in the hands of a novice, which can lead to loss of not only the author's work but also other people's. Using merge almost never results in any sort of loss and is easier to work with for those who still don't quite understand the risks.

Meanwhile the biggest issues I actually see in novices are when their IDE presents them with buttons that don't coincide with a single version control action (can you guess what "sync repo" will do?) and using those puts their checkout into a weird state.

Usually when using the commands directly they're more careful, but have the mindset "an IDE wouldn't intentionally break something so this button must be safe to click".

Re: Hitting every branch on the way down

#127

Post by doix »

btilly wrote: post #124
doix wrote: post #17

Earlier quoted context omitted.

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.

What went wrong was multiple teams on unsynchronized 2 week schedules, and a culture that said that we had to accept the force push when other teams released. So we released at the end of our cycle. It gets used for, if a vague memory serves, end of months billing. Meanwhile someone on another team "merged" our code, and actually randomly dropped a big chunk of our work. A week later they release. Some (but not all)…

I'm pretty sure your code was still around at that point, by default git keeps stuff around for 90 days. Although to be fair I don't know if that's the case today nor if it was the case a decade ago.

What you're describing does sound awful, but I'm pretty sure that idiot could have found a way to mess up a merge. The entire workflow sounds completely fucked, I'm not convinced it's entirely fair to blame rebase in that case.

> Just learn how to merge properly.

I know how to merge and rebase properly. My favorite PR merge strategy is rebase + merge --no-ff. So your master branch is nice and linear, but you can still see where your PR merges came in. Let's you have a "all PRs get squashed" view of the world by just adding '--first-parent' to your git commands, but also lets you have the inner details for when you're git bisecting or spelunking trying to figure out why a certain line exists.

Most people hate what I describe though, similar to mixing spaces and tabs.

Re: Hitting every branch on the way down

#128

Post by btilly »

doix wrote: post #127
btilly wrote: post #124

Earlier quoted context omitted.

What went wrong was multiple teams on unsynchronized 2 week schedules, and a culture that said that we had to accept the force push when other teams released. So we released at the end of our cycle. It gets used for, if a vague memory serves, end of months billing. Meanwhile someone on another team "merged" our code, and actually randomly dropped a big chunk of our work. A week later they release. Some (but not all)…

I'm pretty sure your code was still around at that point, by default git keeps stuff around for 90 days. Although to be fair I don't know if that's the case today nor if it was the case a decade ago. What you're describing does sound awful, but I'm pretty sure that idiot could have found a way to mess up a merge. The entire workflow sounds completely fucked, I'm not convinced it's entirely fair to blame rebase in tha…

My code may have been around somewhere. I suspect I'd done gc, in which case it wasn't. But my git skills then were certainly not as good as they are now. (I'd only recently switched from svn at that point.)

I agree that the workflow was a mess in multiple ways. A lot of which were organizational decisions that I was in no position to influence.

Your favorite PR strategy is fine if you're doing it locally. However when it is done on master, you're going to have to get master again by force. Because changed history creates conflicts. Which means that you're going to have to hope that everyone only did it your way, and no idiot created conflicts in some other stupid way that you'll suffer for later.

I'd prefer to merge to head early. Merge to head often. Merge from head often. Don't have long-running shared branches. This does take some other forms of discipline though.

Re: Hitting every branch on the way down

#129

Post by arghwhat »

tsimionescu wrote: post #72
arghwhat wrote: post #25

Earlier quoted context omitted.

All but the first commit has parents. All commits point to the state of the file tree at that point. A "merge commit" is nothing more than a commit claiming any number of parents greater than one. It is still its own file tree reference that decides how the tree looks, and nothing dictates that it should be related to the parents.

If that were true, then git log -p would have worked. The reality is that merge commits are treated differently from other commits by many parts of git. Saying that they are "just a commit with multiple parents" gives people the wrong impression. Git is more than the data structure backing it. And many parts of git make all sorts of assumptions that treat things that are more or less identical in the data model as ac…

Well, yes - git log does have special handling of commits with multiple parents because everything it shows is a special cased lie. Why? Because commits do not contain diffs or patches, but are instead full snapshots of the repository as a whole at a point in time.

git log -p is a convenience tool that tries to show code progression, and so it comes up with these simple diffs. Showing a graph of N-way conflict resolutions would not help the user trying to get an overview. Other tools exist to track the origin of a particular change, such as git blame.

It is important to understand what a git commit actually is exactly because of the caveats of such convenience interpretations. Otherwise you'd have no idea where a conflict resolution is stored, and you'll run into the surprises mentioned here.

In my opinion, git also becomes a lot easier to work with once you understand the low-level details, as you realize which high-level tools are similar, compatible, or fit or unfit for a a specific purpose.

Re: Hitting every branch on the way down

#130

Post by doix »

btilly wrote: post #128
doix wrote: post #127

Earlier quoted context omitted.

I'm pretty sure your code was still around at that point, by default git keeps stuff around for 90 days. Although to be fair I don't know if that's the case today nor if it was the case a decade ago. What you're describing does sound awful, but I'm pretty sure that idiot could have found a way to mess up a merge. The entire workflow sounds completely fucked, I'm not convinced it's entirely fair to blame rebase in tha…

My code may have been around somewhere. I suspect I'd done gc, in which case it wasn't. But my git skills then were certainly not as good as they are now. (I'd only recently switched from svn at that point.) I agree that the workflow was a mess in multiple ways. A lot of which were organizational decisions that I was in no position to influence. Your favorite PR strategy is fine if you're doing it locally. However wh…

I've never worked anywhere on master directly. Always in feature branches that then get merged to master (ideally with my strategy). So basically master always moves forward and it's history is never rewritten.

Master is always locked down anyway by "something" - no idea what the technical term for Github/Gitlab/Bitbucket is. Stopping people from force pushing to master prevents the sort of stuff that happened to you. Even if you don't have any "idiots", you really don't want a poor intern accidentally slightly pissing off everyone.

> I'd prefer to merge to head early. Merge to head often. Merge from head often. Don't have long-running shared branches. This does take some other forms of discipline though.

I agree with everything there, except I rebase instead of merge. So when I merge my branch to master, it's a nice neat little package that sits on top of master. It doesn't have the history of 10 merges I did while I was developing because I don't see the value in those merges.

But hey, to each their own. When I was younger, I used to get into heated debates about why I was right, now I don't really care. I'm either in a branch of my own and can do whatever I want, or working with someone and then I'll just copy whatever they do to not confuse them.

Post reply on HN