Blazing 💥 fast terminal-ui for git written in rust 🦀 - extrawurst/gitui

https://lobste.rs/s/aejnbw

Commit content is both a snapshot and a patch

Commits are unique and immutable, and are anchored to a specific point in the graph of history and causality. This means that a commit’s identity is made up of both its content and its context. (If a commit has the same content but a different parent, it’s NOT the same commit.)

Branches aren't quite branches, they're more like little bookmark go-karts

And branches don't mutually exclude each other, they don't "own" the branch of history that they happen to be placed on.

git pull exists

"Pull" presents the illusion that you can just ask Git to make everything okay for you so that you're allowed to push again, without having to understand what you're causing to happen, which, as I mentioned at the top, is literally the opposite of how Git operates. It's an incredibly harmful illusion! Can everyone please start teaching novices the basic "fetch, observe, then consciously choose whether to fast-forward / do a merge commit / rebase / reset" workflow instead, thanks.

pollen - book-publishing system

git submodules are always the wrong solution. Yes, even the to the problem they were specifically invented to solve.

• Use git subtree
• Just have a monorepo
• Use a package management system, and explicit dependencies
• Use the multiple repository tool mr
• Have your build expect to find the dependency in .., its parent dir
• Provide an ad-hoc in-tree script to download the dependency

Create a new branch (I often name it test_merge) and switch to it.

Git has a reputation for being confusing. Users stumble over terminology and phrasing that misguides their expectations. This is most apparent in commands that “rewrite history” such as git cherry-pick or git rebase. In my experience, the root cause of this confusion is an interpretation of commits as diffs that can be shuffled around. However, commits are snapshots, not diffs! I believe that Git […]

In my pursuit to understand Git, it’s been helpful for me to understand it from the bottom
up — rather than look at it only in terms of its high-level commands. And since Git is so beautifully simple when viewed this way, I thought others might be interested to read what I’ve found,
and perhaps avoid the pain I went through finding it.

So you've finished your work and are ready to merge your branch back into master. Here's one way to do that very cleanly and safely:

git checkout master
git fetch --prune
git merge --ff-only origin/master
git rebase master my-awesome-feature-1234
git push --force-with-lease origin my-awesome-feature-1234
git checkout master
git merge --no-ff my-awesome-feature-1234
git push origin master

You'll remember that, right? And you'll never mess it up?

For us, we simply run:

git merge-with-master

$ git commit --amend

• Accidentally committed all changes to the master branch
• Forgot to add a file to that last commit
• Added a wrong file in the repo

Check Which Changes You’re About to Pull

If you haven’t worked on a project for a little while, you might want to check what’s happened upstream before you pull all of those changes down into your local branch.

$ git log --oneline --no-merges HEAD../

The Perl Conference 2018

• Revision Control System: track changes

• ~4:30: "This stuff should be taught in schools. If you are not teaching students version control you are doing them a vast disservice. I am super tired of having to spend the first month of onboarding every new junior developer on how to use git."

• ~5:20 Git is not only for code! He talks about text changes, but I think it is also good for tracking binary file changes (but you can't tell the differences).

• https://hellowebbooks.com/learn-command-line/

• ~9:30 git config

• ~15:20 - staging area allows you to build up commits - confusing for newbies

• https://git-scm.com/book/en/v2

• Talk lasts 30 minutes, and then questions: (git rebase)

• https://www.deckset.com/buy/

I soon discovered that rebasing presents some challenges that are not obvious when you first start doing it. Before presenting them, I’ll quickly recap the differences between merging and rebasing.

To avoid messy merge commits and help keep a relatively clean git commit history use the following workflow when fetching upstream changes:

git fetch origin

git rebase −p origin/develop