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

141–150 of 330 posts

Re: The git history command

#141

Post by palata »

xyzsparetimexyz wrote: post #138
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.

No it doesn't. Half the git commands are low level, half are high level. It's not 1:1 at all.

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.

Re: The git history command

#142

Post by amarant »

chrismorgan wrote: post #87
rmunn wrote: post #25

Earlier quoted context omitted.

I have so many branches named `temp` or `before-rebase` for exactly that reason; I'm using them effectively as tags, but branches can be moved around with less ceremony than tags (since tags are designed to be for things like v1.2.3, placed once and then almost never moved again), so I usually just do `git branch before-rebase/some-feature` before running a big `rebase -i`. I've almost never needed to run `get reset…

Diffing diffs is so valuable for that reason, seriously underrated. Once I even found a use case for diffing diff diffs. I also often wish to edit commits or resolve rebase conflicts or whatever by editing the patch rather than the files.

Hey yo,I heard you like diffs, so I put some diffs in your diff so you can diff your diff while you diff!

Sorry, couldn't resist. The xzibit was too strong in your comment.

Re: The git history command

#143

Post by hnfong »

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.

Same here. The git commands were confusing to me until I actually saw a Linus video on youtube explaining how the git data structures worked under the hood. It was dead simple, and one could easily mentally map the tools' functions onto how they operated on the data structures.

Once I understood that, as you said, everything clicked into place.

Somehow the "higher level abstractions" that git tries to do makes the things ever so more confusing.

Re: The git history command

#144

Post by jesse_ash »

palata wrote: post #141
xyzsparetimexyz wrote: post #138

Earlier quoted context omitted.

No it doesn't. Half the git commands are low level, half are high level. It's not 1:1 at all.

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.

> The UI of git directly reflects its internals

Maybe?

Re: The git history command

#145

Post by debugnik »

palata wrote: post #141
xyzsparetimexyz wrote: post #138

Earlier quoted context omitted.

No it doesn't. Half the git commands are low level, half are high level. It's not 1:1 at all.

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.

Re: The git history command

#146

Post by aardvark179 »

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.

Having maintained internal forks, and having needed to pull in and rebase upstream changes I do read a lot of commits. Projects that take care with their commits are much easier to work with.

This is also true when creating with security patches and other things that need to be backported to multiple releases.

Re: The git history command

#147

Post by vasco »

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.

Re: The git history command

#149

Post by locknitpicker »

gbalduzzi wrote: post #112
locknitpicker wrote: post #88

Earlier quoted context omitted.

> What's up with the fix commits? They shouldn't show up in the commit history. In a PR, you merge them in the commit that they actually fix. 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 that is worse than having nothing. Anyone can do better than a fixup commit. And doing metter means merging them into the actual commits that are fixe…

> 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 and curate the set of commits featuring in your PR.

Re: The git history command

#150

Post by locknitpicker »

user43928 wrote: post #139
LtWorf wrote: post #127

Earlier quoted context omitted.

Most people who squash things have never used git bisect, cannot solve a merge conflict and when there is one will just delete the directory and clone everything again. I've worked with such people. They can go on like this for an entire lifetime.

I used git bisect once in 10 years, and it was when I learned about its existence. I am convinced that very few know about git bisect, much less use it regularly.

> I am convinced that very few know about git bisect, much less use it regularly.

Yes, unfortunately not all companies have a high hiring bar. Some

Post reply on HN