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

261–270 of 330 posts

Re: The git history command

#261

Post by ninkendo »

kreco wrote: post #256
ninkendo wrote: post #249

Earlier quoted context omitted.

You've made one and only one point in this thread so far: I'm addressing only that point. You've provided no other elaborations. You're saying "it has a reputation for being confusing, therefore it is confusing." That's a bullshit statement, IMO. If you made any other elaborations on why you disagree with the post you were arguing against, we'd have something else to discuss. But right now you're just posting shallow…

> You've made one and only one point in this thread so far: I'm addressing only that point. You've provided no other elaborations. You're saying "it has a reputation for being confusing, therefore it is confusing." That's a bullshit statement, IMO. I'll repeat myself, I can show you thousands of messages point out how git is confusing. I can show you plenty of message saying "I used X it was fine, but I used git and…

Git has many orders of magnitude more users than other VCS's. The assumption should be that you'd find many orders of magnitude more people finding it confusing than other VCS's. Even if the UX was more or less the same.

I'm also not claiming git isn't confusing (I've explained that it is, in another post), I'm claiming its reputation is undeserved, in that it's not as confusing as people make it out to be. You seem to reject the notion that such a statement is even valid, claiming that reputations are always deserved. I find that to be bullshit.

Re: The git history command

#263

Post by klibertp »

bulatb wrote: post #178
seba_dos1 wrote: post #104

Earlier quoted context omitted.

If the assumption was wrong, then your first comment was pretty much useless, and the second one didn't help either as it just describes doing things carelessly and without proper understanding. So if that reading of it is wrong, then it was just complaining for complaining's sake and not about Git at all, but rather about what you happen to find scary for some undisclosed reason? People do have genuine troubles with…

My point to the OP is the same thing I'm saying to you. "I understand the thing and think it's fine" does not imply that nobody who understands the thing can think it isn't fine, or anyone who doesn't like the thing just doesn't understand it. It's not some deep or interesting idea, but it needs to be repeated any time "git gud" is used as an excuse for Git's UX, which is always.

> but it needs to be repeated any time "git gud" is used as an excuse for Git's UX, which is always.

It's uncanny how a completely different community can have discussions this similar. I wonder if somebody wrote an article like "Git is Dark Souls of VCS, here's 10 reasons why". It could become a hit in both communities (poor potential author, would he even live through that?)

EDIT: I'm doomed. The moment I saw ChatGPT generate this: https://klibert.pl/statics/jolly_collaboration.png ("using GUI frontends is to Git veterans like using summons for Souls veterans") I knew I must write that post; the commonalities are just too funny to pass on :)

Re: The git history command

#264

Post by munksbeer »

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…

It depends on what you think "the right thing is".

Our right thing sounds different to your right thing. Our right thing is PRs less than 500~ lines, and a single logical change only if the overall goal is complex.

For example, in your "right thing" it sounds like you'll have a refactor commit somewhere in the chain of commits in your PR, that might introduce 2000 lines of change, and other logically coupled changes in the same PR, all resulting in a large PR.

We prefer smaller, complete, mergable PRs. And therefore we normally only ever start with a single commit in the PR because the dev squashes everything before raising.

I don't know which way is better, but I do know that when I come across large PRs, I zone out and review quality drops. In fact, I just don't approve them.

Re: The git history command

#265

Post by kreco »

ninkendo wrote: post #261
kreco wrote: post #256

Earlier quoted context omitted.

> You've made one and only one point in this thread so far: I'm addressing only that point. You've provided no other elaborations. You're saying "it has a reputation for being confusing, therefore it is confusing." That's a bullshit statement, IMO. I'll repeat myself, I can show you thousands of messages point out how git is confusing. I can show you plenty of message saying "I used X it was fine, but I used git and…

Git has many orders of magnitude more users than other VCS's. The assumption should be that you'd find many orders of magnitude more people finding it confusing than other VCS's. Even if the UX was more or less the same. I'm also not claiming git isn't confusing (I've explained that it is, in another post), I'm claiming its reputation is undeserved , in that it's not as confusing as people make it out to be. You seem…

[flagged]

Re: The git history command

#266

Post by quibono »

seanc wrote: post #247
quibono wrote: post #169

> scary rebase -i commands that can leave your tree in a half-broken state if you so much as sneeze I'm glad to hear it, I thought that was just me. It gets especially hairy when moving commits around... Plus I have 3-way diffs enabled and I usually get confused by which section is which at least once a day. Also: does anyone know if `magit` has history support?

Not as such, but out of the box you get reword and fixup as first-class rebase macros. I use them all the time. If you wanted to split a commit you'd still have to use a magit-assisted rebase. So if magit added explicit 'history' support I just about wouldn't notice, it would mostly be under the hood.

100% agree, the fixup macro is amazing. It even fails gracefully when unable to commit for whatever reason.

The split one would be handy though.

Re: The git history command

#267

Post by drdec »

InvertedRhodium wrote: post #78
jxf wrote: post #61

Earlier quoted context omitted.

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

Depends what the git history is supposed to show. Personally, I prefer people to leave their mistakes and reversions - though I'd require more description messages than "oops" or "fix", something that explained why it was being reverted or swapped out would be the minimum. Sometimes you try things one way and they don't work out, so you go in a different direction. Capturing why this happened and when can go a long w…

One part of me wishes for multiple levels of logical commits.

When using GH we essentially have one level. The PR is the like a roll-up commit and then we have the component commits it consists of.

It would be nice to be able to say this commit consists of N component commits. Then users can expand or collapse the commits depending on what level of detail they want.

So user A who likes to keep a record of how they actually went through the process with all the warts can have those "messy" commits as component. And user B who likes to see a coherent story told by the commits without unnecessary steps can look at the higher level commit.

But also, git is complicated enough so maybe not.

Re: The git history command

#268

Post by BeetleB »

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…

> If you expect everything to be as easy as pie without needing to make a little effort to read a bit of documentation

Classic strawman.

Re: The git history command

#269

Post by BeetleB »

vasco wrote: post #147
bad_username wrote: post #129

I was uncomfortable with git until I read (the first 3 chapters of) the pro git book ( free here : https://git-scm.com/book/en/v2 ). It provides a great mental model of how git works under the hood. The UI of git - for better or worse - directly reflects its internals. And when I understood them, everything clicked into place.

Mercurial had by far the best UX, never had to read anything to learn it. I just pretend that I'm using mercurial when using git and nuke local repo if I mess up. Been doing it for my whole career.

I loved Mercurial, but once I learned jj, I never looked back.

Re: The git history command

#270

Post by twister2920 »

ninkendo wrote: post #248
twister2920 wrote: post #242

Earlier quoted context omitted.

do you think everyone who claims to be confused by git is making it up? or do you just think you're better than them?

I've elaborated on why I think git's reputation is undeserved in sibling comments. kreco's contention is that "it has a reputation of being confusing, therefore it is confusing", which I think is bollocks. They're throwing accusations of "gaslighting" around. It's valid to think "yes it has a reputation for being confusing, but much of it is undeserved". It's not black-and-white.

you seem very emotionally attached to what is, at the end of the day, just one of many version control systems.
Post reply on HN