I thought that merge commits stored an ordered list of parents, and the first parent is generally the main branch, and second parent is a side branch.
So many times I want to VC a directory but don’t care about commit messages, branching, or other jazz more suited to collaborative work.
With init-lite, all the power of Git is still there - and you can use any commit or command you want, but it’s default would be to simply VC for every file save. In other words, a file save IS a message-less commit.
But if you set that option and run the Assistant, it'll auto-commit files when they change, and can even auto-sync them with other computers, cloud storage, Android devices, etc.
Unfortunately, it required (IIRC) three full time people to administer the server. As for the client (my workstation), it required a proprietary kernel module which would panic about once a week. I'm told our license cost $1m/year (2001 dollars).
Completely agree. I think rebasing is misguided. The objective is to keep history clean and linear. The proper way to solve that problem is with smart log analysis for different customers, not fictionally rewriting the log itself.
Named branches don't really exist in git: there's only a moving target name that refers to a leaf node. This means there's no "history" associated to a branch except for the parent commits. But in merge commits with several parents all parents are considered equal, and the system does not contain info about which commit belonged to the "main branch" and which was imported in. This information can be valuable in some cases. This leads to a lot of rebasing just to keep the commit log clean, but this actually rewrites history and destroys information.
Also, there's no support for keeping two parallel views of the same repository (for example, an internal view with lots of subcommits, and a cleaner public view with more detailed messages, and perhaps fewer privacy-compromising names/timestamps).
Finally, handling merge conflicts is still a PITA, especially on LaTeX documents.