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

181–190 of 330 posts

Re: The git history command

#181

Post by Thanemate »

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.

>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 confused" doesn't mean that "All people are confused".

Re: The git history command

#182

Post by xeyownt »

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.

If you ignore gravitation, a sphere earth can be very confusing.

Re: The git history command

#183

Post by palata »

debugnik wrote: post #145
palata wrote: post #141

Earlier quoted context omitted.

So when someone tells you "understanding X helped me a lot", your answer is "no, it did not"? > It's not 1:1 at all. I don't see any mention of "1:1" in the parent.

They're replying to > The UI of git - for better or worse - directly reflects its internals.

> Half the git commands are low level, half are high level.

Can't we say that the low level level commands reflect its internal? ...

Re: The git history command

#184

Post by kreco »

Thanemate wrote: post #181
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.

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

Re: The git history command

#185

Post by dspillett »

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.

But not as many people are as confused as is sometimes made out. And those who are confused are not as confused as people make out¹. Implying that a great many people are very confused because some are is far more gaslighty than suggesting it isn't that hard in the majority of circumstances, IMO.

--------

[1] many (and I'd include myself here) are fine using the basics, perhaps with some less as-simple-as-possible workflows, but might need to scan the docs if they hit a conflict merging two branches that have developed independently for a fair few commits and have overlaps

Re: The git history command

#186

Post by dspillett »

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.

> 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 management track?

Git is intended to make certain patterns possible, and practical. “Easy for people won't read some documentation” was never one of its design goals.

Re: The git history command

#187

Post by CuriouslyC »

paxys wrote: post #43

I don't get all the effort people spend in perfectly curating git history. No one is ever going back and reading individual commits. Just squash everything before merging and call it a day.

Squashing everything has a significant downside compared to functional atomic commits: git-bisect gets WAY less useful.

Re: The git history command

#188

Post by CuriouslyC »

jxf wrote: post #61
paxys wrote: post #43

I don't get all the effort people spend in perfectly curating git history. No one is ever going back and reading individual commits. Just squash everything before merging and call it a day.

> No one is ever going back and reading individual commits. I violently disagree with this. At a minimum, when I review PRs I look at the commit history to understand what's up. If the path that was taken to commit this is full of "oops" and "fix" messages, it's an immediate reject for me. The commits tell the story and it's a kindness to your human reviewers to not make them work harder to understand the point you'r…

You sound pleasant to work with. I bet your coworkers route around you when they can, and when they can't they cherry pick from their working branch to deliver monolithic commits while rolling their eyes.

Re: The git history command

#189

Post by ninkendo »

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.

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 being confusing, you’re more likely to be scared of certain workflows, you avoid them, and the problem compounds. Similarly if a VCS has a reputation for being “simple”, people might gravitate to it, learn it first, then parrot conclusions that git is too complicated because they never really gave git a chance in the first place (often they do take the time to read the other VCS’s documentation, and if they would have done the same for git they would have had no problems.)

It doesn’t help that there are so many bad tutorials out there that simply give you what commands to run, and tell you dumb stuff like “just make another clone if you get stuck”, and that makes the problem so much worse, and isn’t git’s fault.

Git is a bit confusing sometimes, but it’s mostly for reasons like “the reset and checkout commands do too much”, and “some low level commands are easy to confuse with high level commands” not because it’s a fundamentally confusing tool.

Re: The git history command

#190

Post by kreco »

dspillett wrote: post #186
kreco wrote: post #184

Earlier quoted context omitted.

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.

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

Post reply on HN