Earlier quoted context omitted.
Git is the one treating code like a text file instead of code.
I pull out difftastic when it’s all too hard for this. Diffs based off tree sitter
Don't forget mergiraf, for tree-sitter-based conflict resolution:
The git history command
131–140 of 330 posts
Re: The git history command
#132I 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 do, regularly! In a repository where care has been taken, it can be super valuable when tracking down a bug or regression, and understanding the intent of the author
The debate between these who don't squash and these who do is the debate between these who use the history for bugfixing and those who don't. And I think not using it is throwing away a super valuable tool that can reduce the fix ETA by an order of magnitude.
Re: The git history command
#133Earlier quoted context omitted.
So you're "spending effort in perfectly curating git history" and agreeing with your parent comment.
Just squash everything before merging and call it a day That is also a line from top comment. Everyone read „perfectly curating git history” and went rage commenting instead of reading and understanding what OP wrote.
Nope. Perfectly curating history is indeed the opposite of squashing—you squash because you couldn't be bothered to curate your commits. Squashing is a workaround not an alternative solution.
Re: The git history command
#134git reflog is probably the Git command that has saved me the most stress.
At some point you stop worrying about experimenting because you realize it's surprisingly hard to lose work permanently. Git is muuch more forgiving than it first appears.
Re: The git history command
#135Earlier quoted context omitted.
Do you use git reflog?
I do when I forget to run the git branch comment before. But I find it still hard to understand exactly which commit to reset to in the reflog.
The branch reflog (git reflog or git log -g ) is a lot easier to follow in the case of rebase than the HEAD reflog (which gets an entry for each commit that gets checked out / applied).
Re: The git history command
#136Earlier 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…
The why for a commit belongs in the message or code comments not in the history.
Re: The git history command
#137`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…
It's expensive when you factor in each PR having to wait for someone to come and review it - it's easier to get your work done in larger PRs when that's the case, although it's a perverse incentive
Re: The git history command
#138I 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.
Re: The git history command
#139Earlier quoted context omitted.
I once root-caused a revenue-losing bug that had the entire rest of my team stumped with ten minutes of git-bisect. It only worked that well because the team had all internalized my advice to write small, coherent commits, so the bisect landed on a ten-line change. I strongly dislike the recent trend towards squashing every branch into a single monster commit.
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.
Re: The git history command
#140Tldr; use jj