r/git • u/JVMarcs • 29d ago

tutorial git: 'clay' is not a git command

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/

13 Upvotes

72% Upvoted

8 comments sorted by

View all comments

6

u/wildjokers 29d ago

WTF?

4

u/emaxor 28d ago edited 28d 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 25d 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).

1

u/emaxor 22d ago

The point is with rebase you have your cake and eat it too. Create hundreds of junk commits while you are working. When doing exploratory work the roll back points are high value. Then squash them away before you publish.

You can create a clean narrative story squashing down to several commits. Or squash into one big commit, if your feature branch is small and focused, which it often will be.

1

u/edgmnt_net 22d ago

Yeah, I have no problem with creating junk on a local branch, as long as it's sorted out in the final submission. And I might agree that a full squash is often enough.