>I will award honorary negative points for any client which dares to treat git rebase -i as if it were a fundamental primitive.

If you think that a git rebase is overcomplicated, rather than a fundamental primitive, then you missed an important part of the tool. And phrasing it this way is an insult to anyone who really tried to understand the tool - kind of like the nerd badge in schools.

Git rebase is fundamental to Git in many ways. It is also easy in many ways. At the minimum, it makes it easy to make mistakes while experimenting much less of a hassle, since the commit chain can be cleaned up later.

However, the point here is that git rebase is more similar to what the kernel developers and git developers intended to do with the tool, compared to the commit-merge workflow. There are two aspects here:

1. The tool developers want every commit to be feature-complete and that it won't cause broken builds at least in the master branch. This is impossible to achieve in the regular commit-merge workflow.You need to add the interactive rebases to achieve the goal.

2. Git hides something behind the snapshot model it claims to be based on. The commits themselves are snapshots. But the way changes are propagated between commits (like stashing, commit amending, merging, cherry-picking, rebasing, squashing, splitting, etc) depend on plain old text diffs/patches. It takes a while for beginners to realize this. The kernel devs were using emailed patches and tools like quilt patch manager for nearly a decade before they created git. You can still see the influence of diff, diff3, merge and quilt in the design of git. Knowing this makes you much better at predicting the outcome of these operations. Blaming the tool without trying these techniques is very uncharitable indeed.

I've been learning Pijul these days. All those complicated operations are condensed into a small set of commands in pijul. For one, it concentrates on patches only. I feel that part of Git's complexity is its mixing up of snapshot and patch model into a single program. Git didn't have the luxury of these diff alogrithms back then.

Rebasing is a fundamental primitive, but not Git's implementation of interactive rebasing.

I very much subscribe to a "patch-stack" workflow, but have a great deal of difficulty doing advanced things in Git, because `git rebase`/`git rebase -i` do not support enough workflows.

Here's some features I've implemented which improve on `git rebase` in general: https://github.com/arxanas/git-branchless/wiki/Command:-git-...

Really the fundamentals of git are nodes (commits) and how they connect to each other. Everything else is abstractions on that.

Wonder if anyone has made a git client that lets you manipulate it at that level. Tree looking graph that allows you to drag connections to where you want them.

> Wonder if anyone has made a git client that lets you manipulate it at that level.

I believe you're describing GitUp [1]. I can't really say much about it, though, as I've never used it myself (because it's OSX only).

[1]: https://gitup.co/

https://github.com/git-up/GitUp

> GitUp is built as a thin layer on top of a [Mac-only] reusable generic Git toolkit called "GitUpKit".