Example using llm to generate summary of a doc. Original https://twitter.com/simonw/status/1721644215300714973
curl -s 'https://hn.algolia.com/api/v1/items/38164046' | jq -r 'recurse(.children[]) | .author + ": " + .text' | llm -m gpt-4-turbo 'Summarise the themes of the opinions expressed here. Include direct quotes in quote markers with attribution for each theme. Fix html entities. Output markdown. Go long.'
Rebasing Preferred for Clean History: Some users prefer rebasing because it offers a cleaner, more linear history without the clutter of merge commits.
"I like how Atlassian puts it...The golden rule of git rebase is to never use it on public branches...I still greatly prefer it to the alternative, which is to have merge commits cluttering up the commit history." - (jawns)
Merge Commits Considered Useful: Others argue that merge commits are not inherently bad and can be useful indicators of the work history.
"You can bisect across the more coarse merge commits, without 'destroying' history and losing the ability to bisect across more granular constituent commits. Bisect is more robust when more information is preserved." - (joshribakoff)
Squash Merging as a Middle Ground: Some find squash merging to be a compromise, providing a cleaner history while maintaining change granularity within PRs.
"I branch, merge main in regularly, make a PR, squash back to main and delete the branch. Linear history, single commits for a single piece of work. Easy, clear, no fuss." - (plasticeagle)
Information Loss with Squash Merge: There's a concern that squash merging leads to the loss of valuable commit information that could be used for debugging or understanding changes.
"mablopoule: Yes, but now it's mixed with the bathwater, and now morph into another metaphor as it become the needle in the haystack."
Noise Reduction with Squash Merge: In contrast, proponents of squash merging appreciate its ability to reduce “noise” in the commit history from insignificant commits.
"recursive: Squash merges cut down the noise considerably."
Use of --force-with-lease:
"gabeio:
git --forceneeds to just be an alias of force-with-lease by default. ... It should be something more like:git --force(acts like git --force-with-lease does now) ..."
Use of git reflog and git rerere:
"mbakke: git rerere only 'automates' conflict solving after you already solved it. As in, it remembers previous merge resolutions, even if you undo the merge/rebase."
Interactive Rebasing rebase -i:
"timost: IMHO
--fixupcommits and--autosquashrebases make rebase much easier."
Avoid Rebasing Shared Branches: It is largely agreed upon that rebasing should be avoided for branches that are shared among team members to prevent disruption.
"sdfghswe: Don't rebase ESPECIALLY stuff that people are collaborating on."
Collaboration on Feature Branches: Some users actively collaborate on feature branches, and they exercise caution with rebasing in those cases.
"dewey: ... in my experience I sometimes collaborate on feature branches with 1-2 people and we just communicate when there's a rebase happening ..."
Learning Curve: Users highlight that improper use of rebase can lead to disastrous consequences, which might reflect a steep learning curve for some developers.
"I've found that consistently using the --onto flag when rebasing helps prevent errors by ensuring the target hash of the rebase is always explicitly specified." - (hoelter)
Ease of Use: Several users feel that using rebase becomes second nature once you fully understand it, even though there's an initial struggle.
"One day you can suddenly 'get' rebase, and then you almost never need to think about it ever again." - (PaulDavisThe1st)
Emotion Attachment to Commit History: There's a suggestion that discussions about git usage can become emotionally charged, reflecting developers' attachment to their preferred workflow.
"jwmoz: Nice to see no one agrees on how to use git correctly."
Ego-Idealization of History: Some comments hint that the "clean history" preference might be tied to a desire to present a more idealized narrative of development.
"anon23432343: It’s ego"
Debugging Granularity: A number of comments point out that having detailed commit history can greatly aid in debugging, especially when using tools like git bisect.
"If I had a bad day and introduced something stupid, I want a bisect to point me at the code I wrote on that bad day." - (MatrixMan)
Project History Comprehension: Understanding the sequence of changes in a project is critical, and a well-maintained commit history can make it easier for future developers to comprehend a project's evolution.
"A repository shouldn’t be a dump of unmeaningful commit messages, but a curation of best contributions at the time of commitment." - (heldrida)
Simplicity Over Git Management: Some users suggest that focusing too much on git management strategies can be an unnecessary overhead that takes away from actual productive work.
"jarek83: 'Don’t make me think' has been the best principal of coding for me for a long time. Looking at how much thinking overhead rebase is producing, I’d prefer to avoid it."
Acceptance of Messy History: There is an argument to embrace the "messiness" of development history as it reflects the true, sometimes chaotic, nature of software development.
"Let it go. Accept that coding is not a smooth, robotic, endeavor, where everything is always tidy." - (AndrewDucker)
Overall, the discussions reflect a diverse range of preferences and philosophies toward git usage. From valuing clean and linear histories to accepting the reality of complex development processes, each developer or team tends to settle on the workflow that best suits their needs, project requirements, and level of git expertise.