See this for a proper evisceration of rebase and what a proper tool would do:

https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md

This is yet another article that doesn't really seem to get it. For example: it argues that many small check-ins are better for bisecting -- but enabling a development process that encourages many small commits while still allowing bisect to work is one of the big reasons of rebase's existence! (Perhaps the author is biased/doesn't understand common use cases because SQLite has a famously thorough test suite that almost nobody else comes close to. SQLite's development flow is also comparatively simple: the Linux kernel, for example, has orders of magnitude more developers.)

That said, it gets quite close to an interesting idea here:

> Second, if Git remembered the source of cherry-picks in commits, Git users might have a better argument for avoiding rebase, because they’d have an alternative that didn’t lose history.

I like the idea of properly remembering cherry-pick sources in commit metadata. It would be a cool thing to have, and potentially sometimes useful.

But try to really imagine a world where this is how Git worked. How would you solve the two problems I stated in my GP comment? You'd just transform state A of a branch into state B by performing a sequence of cherry-picks. And that's pretty much exactly what git rebase is...

So no, the author's proposal wouldn't eliminate the need for the rebase flow. It would subtly change the result of a rebase in a way that preserves more history. Which may or may not be useful, but I mostly wouldn't mind it.

(Just for your consideration, losing history can be important when you're maintaining a mixture of open and closed source / trade secret branches. You may not care personally, but being pragmatic about such things has certainly helped git.)

> Perhaps the author is biased/doesn't understand common use cases because SQLite has a famously thorough test suite that almost nobody else comes close to

I'm sure they understand the use cases quite well, and designed their Fossil VCS to address these faults.

> And that's pretty much exactly what git rebase is...

Except rebase disconnects it from the history where the author's solution does not. A view on a SQL table does not change the underlying data, it just presents it differently. That's the difference between what the author's proposal and yours.

This could work with "meta-commit" messages added to groups of commits after the fact. Such messages could be parsed by the log display program. Git notes is the obvious tool for adding such metadata.