> > The closest I have found is the network, which is slow to render (unless it is already cached), does not offer nearly as much details, and scarcely works at

> > The closest I have found is the network, which is slow to render (unless it is already cached), does not offer nearly as much details, and scarcely works at all on mobile. (The preceding text in TFA makes it clear that this refers to rendering a view of history. This is in a section titled "Git does not provide good situational awareness".) Here's the thing: if you use a rebase workflow then all history will be linear, and that requires nothing fancy for rendering, and it's fast. That's NOT the reason to want to use a rebase workflow, mind you. Fossil doesn't have rebase (though it has cherry-pick, which is the building block for rebase), and D. R. Hipp seems pretty proud of this. I understand his and many others' dislike of rebase, but I believe that dislike is founded on some confusion. I believe rebase workflows are -where they are possible- superior to merge workflows, and that linear history is superior to non-linear history. Let's start with linear history vs. non-linear history. Our brains are very linear, so I think that instantly makes linear history better. It's easy to see that history with lots of branches and merges is non-trivial to understand, and this is much more the case the larger the team of engineers and the larger the number of distinct branches (projects, bug fixes) involved. For example, at Sun Microsystems, Inc. (RIP) we had over 2,000 engineers working on OS/Net, which is the core of the Solaris and Illumos operating systems. At Sun we had a strict linear history mandate, which meant we were using a rebase workflow long long before Git came along. If we had not had that mandate then OS/Net's history would have been incredibly difficult to visualize since one would need a display that could fit hundreds if not more parallel branches. If you actually want to visualize history, then merge workflows just won't scale with project complexity. One might object that, well, for such projects as OS/Net one just wouldn't even attempt to visualize history like that, that one would filter branches of interest and so on. But this comes for free with linear history as with linear history there is no need to attempt to filter what branches get rendered because there is only one branch at all times. If you care about history, what you really want is to see what's changed over time, and that is always linear. At time t_n you have some commit, and at t_n+1 you have some other commit, and so on. That some are merge commits only obscures the fact that if you're spelunking through history (e.g., bisecting), the history is just linear. All those merge commits do is act as something like text folds in editors, hiding away some sub-history, but if you're looking through it then you really do care about the details and you don't want that history hidden. On the other hand, if you're not browsing through the history, then you don't care if there's merge commits or not. So you should just not care for merge commits at all. Linear history is just easier to understand. Yes, you want to squash unnecessary commits before pushing to avoid cluttering history with noise -- no one cares about what typos and brainos you made while writing some bugfix or feature commits, and certainly no one will years after you push. Because rebase workflows lead to linear history, and linear history is better than non-linear history, rebase workflows are better than merge workflows. But also it's just easier to understand rebasing than merging once you understand cherry-picking. At least for me it is. But I think it should be easier for more people too, if only it rebase were explained that way and explained before merges. Besides, if you have N commits in a branch and you merge it into another, when you resolve conflicts you won't know which conflicts and resolutions go with which of those N commits, and you won't care, but if you want to understand your work -and also others to understand your work- it seems much better to rebase and resolve conflicts commit by commit. Getting back to "situational awareness", linear history gives you just that. It's merge workflows that make it hard to be aware of all the recent changes.