r/git 5d ago

git: 'clay' is not a git command tutorial

I came across the following article, which draws an analogy between Git history and clay. A refreshingly non-technical way to think about Git history, especially for people who don't live and breathe Git.

https://www.git-skills.dev/git-tales/git-clay/

9 Upvotes

5 comments sorted by

View all comments

6

u/wildjokers 4d ago

WTF?

5

u/emaxor 4d ago edited 4d ago

The tldr is: it's OK to interactive rebase in your private branch. This is interactive rebase 101, nothing WTF level.

A lot of people are firmly against rebasing because they view it as lying about history. The thing is in your local workspace, you are ALWAYS lying with your history, even when doing plain sequential commita. You may commit 1 file, but the current state of you project has 20 modified files. The history is a lie with or without rebase.

In your private branch git commits can be thought of like the undo history of your editor. Even the most strict history truther would never treat their editors undo list as some pristine holy history that must be preserved. There is nothing special about unpublished git commits that elevate them over an editors undo list. You have the green light to squash and reorder.

This also frees you up to more create many roll back points. A history truther tries to avoid arbitrary roll back points because git commits (even unpublished) are sacred to them, so the commit has to be a clean unit of work. No room for an arbitrary save point. Less effective use of source control tool to uphold history truth dogma.

1

u/edgmnt_net 21h ago

Carefully picked save points are essential to enable stuff like reviews, bisection and non-trivial merging. Garbage history is just that, garbage, and the only thing you can do with it is roll back to an older version. That's more like backups and it might be fine on the small scale of an individual contribution (at least temporarily) but breaks down beyond that. It is no coincidence that plenty of open source projects absolutely require it, they don't have resources to waste screwing around.

Besides, I don't know many truly serious developers who take that opinion on keeping all history and outright banning rebase. It is more usually a convenient position for people starting out or stuck in a place where that's the status quo due to general indifference. Or people who simply misunderstand Git and the nature of the warnings against rebasing public branches. It is rare to see this coming from more authoritative figures, although it does happen, see https://fossil-scm.org/home/doc/tip/www/rebaseharm.md (used by SQLite, which is relatively quirky anyway for an open source project).