Git is not nearly as confusing as people make it out to be. They just never take the few hours it takes to understand it. Which is a sad state of affairs for such an essential tool in the belt of any software engineer.

    git commit -am “Changes”

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.

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

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.

You don't even need to set a safety tag like that anywhere in git, the reflog does that for you automatically.

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 before-rebase`. But I have often done `git log -p before-rebase` and compared that to the post-rebase state of the branch, to ensure that the merge-conflict resolution(s) that came up during the rebase haven't accidentally introduced an unintended change.

Do you use git reflog?

> `git rebase --abort` exists

Exactly. 50% of the times I type git rebase it is followed by --abort.

No need for that even. Just git reflog and rewind back to any spot your want!

I also took a leap in organization. But I don't think you're responding to git in particular, just a source control system.

git (and other version control systems) take what you made, organize and preserve it, and you can get any number of copies at a moment's notice.

It is good for people to be able to do work and not worry about it.

I remember reading David Allen's book Getting Things Done years ago. It takes effort to read through his writing, but he had good ideas.

One thing he mentioned is that you need a 'trusted system' where you can collect and organize your thoughts. It lets you offload what you're worrying about until the time you need to do something with it.

I actually use omnifocus to do this for my tasks/projects/lists, but for what I actually do on a computer, I trust git to organize and preserve the software (and some data) I have written.

How do you use it for music composition?

Woah! That feels like a huge oversight and like it bypasses standard commit logic. The man pages do say `git history` is experimental. Sounds worth a bug report.

Same, but at the same time the existing workflow is a bit more clumsy / these commands are a bit more ergonomic.

Fixup was already possible through `git commit --fixup`, and before that through `git rebase -i`; reword also through `git rebase -i`. I suppose the developers got enough feedback that editing a file to decide what to do with each commit was a bit frustrating for some users.

It's a higher level command on existing functionality I suppose.

In terms of UI for Git, I've never seen anything getting remotely close to Magit. It's both in-depth and a simplified stateful interface.

Here's what I mean by "stateful": one of the huge problems with command-line tools is that their output becomes mostly inaccessible upon subsequent invocations. Suppose you ran git-log, and now you want to apply the knowledge gained from reading its output to your next action (say, you want to cherry-pick a commit). But you are lucky if the hash of the commit in question is still somewhere in the terminal. Otherwise... you aren't writing that from memory...

Stateful UI to command-line tools allows multiple interactions in parallel and preservation of information obtained in previous interactions.

Git needs a lot of state. You need to remember facts s.a. what branch you are on, what branch did you switch from, what files have been modified, what commits haven't been pushed etc. The requirement to remember all of this is overwhelming and makes the effective use of the tool difficult. This is where various tools come to help (eg. Shell plug-ins that provide auto-completion or modify the prompt to incorporate some of that state info).

I believe that people complaining about difficulties of using Git are often handicapped in their use of surrounding tools that would otherwise mitigate the problems above: they don't know how to add Shell plug-ins that display the current branch, they don't know how to have multiple tabs/panes open in a single terminal session, how to copy text between those tabs/panes, they don't know how to invoke / search auto-complete options.

Genuinely, if you don't have tools to help you use Git, something that people who are used to navigating the world of terminal UI, using Git becomes very unpleasant.

> 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're trying to get across.

> 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

I’m with you, but it’s obviously a sensitive topic for a lot of folks, based on the replies. Some people’s brains are just wired differently, I guess. I rarely look at history, other than git blame. For me, history does not need to be granular at all. The replies make it sound like curating git history is the job, rather than shipping solutions to customers’ problems. I guess, if it helps you ship faster / better, more power to you.

> No one is ever going back and reading individual commits.

Straight from the git-log, maybe not, but sometimes you see code that makes you wonder how it came to be and it can help a lot to see it in context of the commit that introduced it. That'd be less helpful if that commit were some huge thing making lots of different changes at once.

How do I know you don’t work in a big team from this?

First thing I do every time I come back from vacation is to read through our git history to see what has happened.

It is also very useful when CI breaks. In fact I probably use some form of git history reading every day at work.

Also if your code base is so tiny and the features you work on are so small that you can just squash everything then maybe that is fine for you. I definitely love being able to actually see what is going on and selectively cherry picking or reverting commits

Having a well curated one-logical-change-per-commit history is incredibly valuable when bisecting a regression.

I am always aghast at how proudly people pronounce that they don’t know how to use one of the most central and essential tools in the belt of a software engineer.

Maintaining history is well worth it, and allows you to use tools like

    git rebase
    git revert
    git bisect
    git blame
    # …

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.

Squashing everything has a significant downside compared to functional atomic commits: git-bisect gets WAY less useful.

I have a more nuanced view of this; in libraries and software projects that span years like Linux, curl, etc, this happens all the time. Bugs get fixed and they can point to the exact commit where it was first introduced, and that commit contains all information necessary to figure out why it was introduced in the first time.

But that's projects like Linux, which is a whole different use case than for example what I do for a living, front-end applications that have at best a lifespan of 10 years and whose individual features / screens / components have less than that, and it's much more rare that an older commit is still relevant today.

(that said, looking history up has made me dislike squash commits. I get it from a pragmatic point of view but it's not ideal)

I do multiple times a week, with repos that have barely been touched in a decade and all the original devs are gone. Squashing would make figuring out why something is the way it is a lot more painful, so I'm glad these repos are svn where squashing wasn't an option. Several times I've discovered bugs that were introduced in linting commits that would have been squashed, so the fix ends up trivial since the intention is already there in the previous commit.

Of course we do and it helps tremendously when the graph is reasonable.

One use-case for curating commits other than git history is carefully structuring code reviews to be easy to review. Eg "commit 1 just rearranges existing code, no business logic changes"..."change 2 modifies business logic, but in one localized place as the refactoring has already been done"..."change 3 only modifies comments"

Disagree. You need small, git bisectable commits. Use stgit to do it and it's nearly effortless.

I could count the number of times I've written a detailed summary in the body of a commit message, and had it read by my colleague reviewing who then didn't need to leave a comment on the PR asking why I did _x_ on zero hands.

One good reason is to keep your tests separate from the fixes that make your tests pass. That way you can check your test fails before the next commit makes it pass, eliminating the risk of a false negative (test passes that would have anyway).

Sorry, no. Just because you've never done it doesn't mean that no one ever will.

Beyond the archival benefits, I've found plenty of bugs by going back through my "wip" commits and creating a sane history from them.

That is like saying once the program is done, throw away the source.

Lemme guess all your for commit say "wip"

I almost never went back to read the history, but now I often have Claude go through the history when I wonder how we got to a certain point. It can point me to the relevant issues as well. Squashing is fine, up to a point.

> No one is ever going back and reading individual commits.

Hell yes we are! Just because you aren't going to doesn't mean nobody else is going to.

Might as well go back to the tar.gz days, eh?

> No one is ever going back and reading individual commits.

Your assumption doesn't match the real world practices I've experienced for years across multiple jobs. Even at the PR stage a clean commit history is of critical importance. Nowadays, with ai coding assistants assuming a central role in developing software, commit history is even used as input with context signal, allowing for flows such as "evaluate the changes in commit X and Y and apply the same pattern to project Z".

Just because you don't use a tool properly that doesn't mean everyone around you makes the same mistake.

Spoken like a guy who really really doesn't understand how git works and has never bothered to learn!

I do not agree at all. When you have multiple repos accross different services, commits are the best way to follow up with differents changes. We adopted conventional commits guidelines a few months ago and everyone is happy. Even ClaudeCode is able to keep up and auto fix stuffs with the proper commit messages. The changelog is dynamically updated. Everything so smooth when those commits messages are perfectly synchronized.

Wonder if the history command is all that useful.

I prefer the interactive rebase and use it frequently.

Would much rather “visually” move commits around than accidentally aim “git history” at an orphaned commit hash no longer in my local branch.

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 changes of the other PR so they should review that one first. Should they want to add changes to the first feature, they just need to checkout that branch, do the changes, and merge to the second feature branch so they're available there.

What does it mean to split a branch in two?

> I'll end up with this state, where `E` remains untouched?

Can't, because a commit's hash takes into account the parent hashes.

Haven't used --update-refs, but reading it, it should result in your third graph. So,

> is there a way to get `git rebase` to have the same behavior?

is already the case.

See: https://blog.hot-coffee.dev/en/blog/git_update_refs/

off-topic, but that is a very clear readable comment you left with those line-drawing characters.

> commit messages while writing the code, will reorganize and clean them up later anyway

That's just too primitive of a workflow, so repeating it will not run into the risk. You need to add an actual conflict in some feature branch and get stuck being forced to resolve it to compete the rebase to appreciate the op warning

Commit graph is just a data structure. Sometimes it represents a "history", sometimes other things.

Personally, I like it when project's repository represents the history of the project rather than the history of random things developers do on their machines, but you do you.

You probably shouldn’t be committing things that are broken…

That's not possible, because files don't have ancestors in git. Each commit's tree is tracked independently and copy/move is just something that's detected via heuristics.

Yeah I learned that one a few months ago, before that I'd use interactive rebase and shuffle the commits around manually in the editor that opens.

I appreciate that these commands are just utilities / conveniences on top of a stable base though.

Git is the one treating code like a text file instead of code.

I can fully understand a conflict, know it's coming, and fear it anyway because I'll have to deal with Git's behavior to fix it.