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

The git history command

lalitm.com

Post reply on HN
Print view View original

191–200 of 330 posts

Re: The git history command

#191

Post by CuriouslyC »

locknitpicker wrote: post #149
gbalduzzi wrote: post #112

Earlier quoted context omitted.

> Otherwise when you use git blame to get the context of why a line of code was changed, all you see is a useless "fixup" message Isn't this solved if you squash the commits when merging the PR? I personally don't care that much about the commits inside a PR, the are just temporary because when a PR is merged they are squashed and you only get one commit for the whole feature on the main branches

> Isn't this solved if you squash the commits when merging the PR? In theory, yes. Squashing is an extreme approach to merging fixup commits. It also throws the baby out with the bathwater by removing individual commits that explain and clarify how and why some changes were introduced as part or a PR. If your PRs are tiny and don't introduce major changes then squashing is ok. Instead, you should do the right thing a…

Making small atomic commits as you go in the age of AI tends not to go great because it forces too much human in the loop in a lot of cases, and the percentage of AI code rework is significantly higher than manual code, so the history tends to be harder to keep clean.

It's ironically easier to create a messy agent work branch then have the agent cherry pick independent PRs from it into atomic commits post-work.

Re: The git history command

#192

Post by CuriouslyC »

jolmg wrote: post #46
paularmstrong wrote: post #7

`git history split` is really going to help me help juniors break up their large PRs into smaller more concise changes. If only it had the option to split an entire branch in two easily.

Maybe the issue is they think of a PR as an expensive thing. Would be best if they could just do the small thing and make a PR of that from the get-go. If they want to base future changes on the ones they just did, they can just create a new feature branch from right there, and just not create the PR of the second feature until the first is merged, or create it and add a note to the reviewer that it includes the chan…

Small stacked PRs are a NIGHTMARE unless your org is consistently turning around PRs in low single digit hours, and team members are working on decoupled code so you don't have any stack weaving. You end up in a situation where the engineering director and some tech leads really like tools like Graphite, while the entire team working under them mutters irately under their breath daily.

Re: The git history command

#193

Post by kreco »

ninkendo wrote: post #189
kreco wrote: post #180

Earlier quoted context omitted.

> Git is not nearly as confusing as people make it out to be. The people are confused, it's a fact. So it is confusing. Stop gaslighting people.

There’s this important word in the sentence you seem to be ignoring: “as” GP isn’t saying “git isn’t confusing”, they’re saying “git isn’t as confusing as people make it out to be” The point being, people exaggerate git’s confusingness when discussing it. There’s an element of irrationality here that’s worth bringing up, especially when it comes to comparing it to competing software. Once it has a reputation for bein…

[flagged]

Re: The git history command

#194

Post by jamesnorden »

kreco wrote: post #190
dspillett wrote: post #186

Earlier quoted context omitted.

> Let's not start to bend reality just to back up some narrative because after reading a N hours documentation everything is OK. If you expect everything to be as easy as pie without needing to make a little effort to read a bit of documentation, then perhaps the problem is not the product but the fact that you are in the wrong industry, or the wrong role within that industry, for you. Have you considered a managemen…

You conveniently cherry picked the least relevant part of my message. No one said everything should be easy as pie. There are other software similar to git that have not such reputation. Version control is not new.

Because people actually use Git instead of whatever you mean.

Re: The git history command

#195

Post by nixon_why69 »

hackrmn wrote: post #179
Hendrikto wrote: post #171

Earlier quoted context omitted.

Git is not nearly as confusing as people make it out to be. They just never take the few hours it takes to understand it. Which is a sad state of affairs for such an essential tool in the belt of any software engineer. git commit -am “Changes” just does not cut it, if you call yourself a professional.

My observation has been that those who have never learned Git properly -- disregarding for a moment the issue with what "properly" means here -- just don't think they need to, sticking to very simple workflows that produce linear graphs featuring squash-rebased work throughout. Because they don't know Git's fundamental model (including what you'd think was the obligatory piece of information that commits are essentia…

Ok but the final outcome, most of the time, is a linear graph unless you're maintaining extremely long-lived branches for some reason.

Setting practices so that linear graph will be easy to understand in history is still a good idea, no? I'm not religious about squash-merge on master but when I look at master's history, I'd expect each individual commit to have a good message and be releasable.

Re: The git history command

#196

Post by hackrmn »

nixon_why69 wrote: post #195
hackrmn wrote: post #179

Earlier quoted context omitted.

My observation has been that those who have never learned Git properly -- disregarding for a moment the issue with what "properly" means here -- just don't think they need to, sticking to very simple workflows that produce linear graphs featuring squash-rebased work throughout. Because they don't know Git's fundamental model (including what you'd think was the obligatory piece of information that commits are essentia…

Ok but the final outcome, most of the time, is a linear graph unless you're maintaining extremely long-lived branches for some reason. Setting practices so that linear graph will be easy to understand in history is still a good idea, no? I'm not religious about squash-merge on master but when I look at master's history, I'd expect each individual commit to have a good message and be releasable.

A linear graph doesn't do any developer in the team except Github (which isn't a developer in this context) any good because they have to pull down the graph at some point and when they have to fix something, although they will be able to track the blame to some commit in the middle of the graph, when they fix it and merge it it has to be squashed again (by hard or soft enforcement), which like I said negates much of the point with Git -- there's no usable history left.

Point being that branches aren't something to avoid, implying that complicated graphs are not to be avoided either, but embraced and knowing how Git works it's not a problem at all (unless your "bush" is accidentally complex in a bad way) -- except that if noone bothers to learn Git, it _becomes_ a problem, solved at the cost of the value that Git provides -- branching (not just ephemeral branching for your local convenience). Exacerbated by Github since everyone pulls from there -- meaning that production-grade code is not a true graph but a linked list, on average.

Re: The git history command

#197

Post by kreco »

jamesnorden wrote: post #194
kreco wrote: post #190

Earlier quoted context omitted.

You conveniently cherry picked the least relevant part of my message. No one said everything should be easy as pie. There are other software similar to git that have not such reputation. Version control is not new.

Because people actually use Git instead of whatever you mean.

This is irrelevant to the topic.

I didn't ask why git was widely used. I didn't say git was useless.

Again, there were version controls before git came out.

Re: The git history command

#198

Post by ninkendo »

kreco wrote: post #193
ninkendo wrote: post #189

Earlier quoted context omitted.

There’s this important word in the sentence you seem to be ignoring: “as” GP isn’t saying “git isn’t confusing”, they’re saying “git isn’t as confusing as people make it out to be” The point being, people exaggerate git’s confusingness when discussing it. There’s an element of irrationality here that’s worth bringing up, especially when it comes to comparing it to competing software. Once it has a reputation for bein…

[flagged]

You just did though…

Maybe try and explain in more than one-sentence quips why you think git deserves its reputation? Otherwise you’re just coming off as a bit of a troll. Have a nice day.

Re: The git history command

#199

Post by xelxebar »

kreco wrote: post #180
Hendrikto wrote: post #171

Earlier quoted context omitted.

Git is not nearly as confusing as people make it out to be. They just never take the few hours it takes to understand it. Which is a sad state of affairs for such an essential tool in the belt of any software engineer. git commit -am “Changes” just does not cut it, if you call yourself a professional.

> Git is not nearly as confusing as people make it out to be. The people are confused, it's a fact. So it is confusing. Stop gaslighting people.

Interesting. "A is X" is different than "I experience X from A". The former employs an objectivist lens while the latter a subjectivist one. I have had the pleasure of witnessing debates about whether a room really, truly is cold or not, which all resulted from a simple "it is cold in here" comment. In my experience modern English speakers tend to bias toward the objectivist register while Japan tends the other way. One of the joys in my life is how absorbing languages and cultures elucidates previously-unperceived distinctions. This discussion makes me want to try picking up Ithkuil again.

/r

Re: The git history command

#200

Post by ninkendo »

kreco wrote: post #184
Thanemate wrote: post #181

Earlier quoted context omitted.

>The people are confused, it's a fact. So it is confusing. Stop gaslighting people. I don't think this sort of aggression is warranted, as the fact that I find something confusing doesn't directly imply an intrinsic feature of the object that I'm confused with. One can reach that conclusion by observing that, not everyone who learns about the object finds it equally confusing. All that to say: "The people are confuse…

There is no aggression. If your product has a reputation to confuse users compared to other products, your product confuses users. Let's not start to bend reality just to back up some narrative because after reading a N hours documentation everything is OK.

> If your product has a reputation to confuse users compared to other products, your product confuses users.

Is your contention that all reputations are deserved, by definition? That’s certainly an interesting take. It leaves zero room for the concept of an “unfair reputation” for example. Maybe you should rethink your argument here.

Post reply on HN