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

131–140 of 144 posts

Re: Hitting every branch on the way down

#131

Post by Groxx »

noirscape wrote: post #67
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…

My personal preference is merge but using the --no-ff flag. That way you get all the advantages of a rebase (since all your original commits are rebased into the target branch) but you also get a merge commit to confirm that all those changes were a part of the same set of patches. That can often help a lot to figure out why something ended up the way it did, but you also don't turn your entire history into a flat pi…

Yeah, I do kinda like this setup too. You can have both readable (rewritten) history and structured sub-commits for "a change" rather than a totally flat stack. Plus I don't care about your local history, but I do care about the final history.

It's definitely how I prefer to review code (big changes broken up to isolated portions that are easier to validate, and the whole thing at once so you don't get lost in the trees), so it's how I would prefer to read it later too.

It does still have merge commits where stuff can hide though :/ and you've got to remember --first-parent :/ and all not-merge-focused things so have problems with it :/

Re: Hitting every branch on the way down

#132

Post by Groxx »

Izkata wrote: post #126
wdfx wrote: post #55

Earlier quoted context omitted.

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 cl…

Custom terms on top of git is a bafflingly bad decision.

IDEs in particular should expose the details all the time, and show the command that's being run, so it can teach people passively instead of misleading them and leaving them stuck when it breaks.

Re: Hitting every branch on the way down

#133

Post by Izkata »

torstenvl wrote: post #92
CoastalCoder wrote: post #89

Earlier quoted context omitted.

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.

Isn't that what a branch and a merge commit do?

Yep, as long as you use "--no-ff" to force a merge commit (and presumably edit the merge commit message instead of just using the default).

For viewing history you can use "git log --first-parent" to view only those merge commits, which should satisfy the people who love a linear history, without actually losing the intermediate commits.

Re: Hitting every branch on the way down

#134

Post by tsimionescu »

arghwhat wrote: post #129
tsimionescu wrote: post #72

Earlier quoted context omitted.

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 resolu…

What git log shows is not "a lie", it is a part of its data model. Git is all of its commands, not just the low level details. Commits are both snapshots of the entire repo, and diffs, and delta compressions - none of these is "a lie".

Re: Hitting every branch on the way down

#135

Post by btilly »

doix wrote: post #130
btilly wrote: post #128

Earlier quoted context omitted.

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…

Unless the strategy is really bad, I'd prefer to go along with what everyone else does. When multiple people push their preferred optimum, the resulting inconsistency is clearly worse than a single suboptimal, but consistent, approach.

Re: Hitting every branch on the way down

#136

Post by citrin_ru »

quectophoton wrote: post #88
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.

I can give an example scenario. Assuming "H" is the hash of the current state of the repository content, consider this initial state of the repository (most recent first): H(3) Implement feature B H(2) Implement feature A H(1) Initial commit Now you implement "shiny feature", so your history in your branch looks like this: H(5) Shiny feature, improvements. H(4) Shiny feature, initial implementation. H(3) Implement fe…

To avoid this you can squash H(9) and H(10) before pushing to a shared branch, this way only one tested commit will be added on top of existing commits.

Re: Hitting every branch on the way down

#137

Post by RHSeeger »

msteffen wrote: post #117
RHSeeger wrote: post #102

Earlier quoted context omitted.

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

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

This seems to imply that there's a choice between A) committing to the main branch, and B) long lived branches. I always work on branches, almost always with multiple commits, and then merge it into the main development branch once the feature is complete. I almost never have to deal with complicated merge conflicts.

That being said, you're talking about short lived branches. The article talked about committing directly in the main trunk/master branch; which is what horrified me.

Re: Hitting every branch on the way down

#138

Post by microtherion »

lloydatkinson wrote: post #64
microtherion wrote: post #40

Rather than the sed post-processing, the author could also have used -iquote for the place where protobuf is installed, which makes it findable by quoted includes.

Is this a common solution or documented in obvious places? It wasn’t until I just read her article that I’d even considered some systems/distros doing weird things like rewriting C include syntax for questionable reasons. What a terrible thing to deal with, simply frustrating.

It is documented in the gcc and clang documentation. It's also described in the gcc manpage, but not the clang one.

I don't know how "common" it is, but when dealing with third party code, I run across / "" confusion quite commonly, so when that's a significant part of your job, you'll probably stumble upon this flag eventually.

Re: Hitting every branch on the way down

#139

Post by saghm »

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.

I don't understand how either of those links clarify anything; the former shows that they had a version 3.y.z and a version 20.y, and the later shows a change from 3.20.x to 4.21.x, but none of it gives any explanation for why a new major version should "inherit" the old minor version instead of restarting from 0, or why they kept around `x.y` when updating to use `x.y.z` instead of just continuing the existing branch as `0.x+1.y` or `1.x+1.y`. If anything, the fact that they already seem to assume that new major versions should always inherit the minor version would make it _more_ consistent than having one "special" branch that has "narrower" versions.

Re: Hitting every branch on the way down

#140

Post by bitcharmer »

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.

That depends. In low latency environments you will see some protobuf but not as much as you'd think. SBE is quite common with the odd exception of some bespoke serialization protocols with delta compression and such.
Post reply on HN