I'm scheduled to give a talk in a few weeks at the Southeastern Linuxfest (http://www.southeastlinuxfest.org/) titled: "Git: Just Say No!" I have a good outline, but your input will still be appreciated.
The published description of the talk is: Git is the most widely used version control system (VCS) for open-source projects. But it is also the most difficult to use, the most confusing, the most brittle, and the most likely to lose or mangle your work. This talk will review some of the problems with Git and offer suggestions on how those problems might be fixed. The talk will explain why developers ought to either use another (any other) VCS or else should be hounding the Git maintainers to fix its many shortcomings. (Full disclosure: The presenter is the lead programmer on a competing VCS.) This is not a talk about Fossil, though my work on Fossil will certainly inform the talk. I'm not planning to push or pitch Fossil - that would seem rude. Nor do I intend to offer any criticisms of Git for which I will not also present specific solutions. Below is a list of problems with Git that I intend to discuss, in priority order. Please offer your help in reprioritizing and also suggest additional areas of deficiency. If you have anecdotes, quotes, or case studies that I can share, that would be great too. Your help is much appreciated. Current Problems With Git: (1) Git will not show you the decendents of a check-in. This seems to be a biggie and one that resonates even with staunch Git advocates. I'll spend a lot of time on it, getting down into the reasons why this is and offering a technical solution that could be added to libgit without too much effort. (2) Multiple check-outs per repository. How can you possibly get any work done when you can only have one branch open at a time? Having multiple clones of the same project is a work-around, but not a particularly appealing one. (3) A busybox version of Git - the entire VCS in a single binary that you just drop into your $PATH (4) The ability to check-out and clone "slices" of a repository. In other words, clone only selected subdirectories of a large project. (This is a capability that Fossil lacks too.) (5) The ability to check-out from a remote repository. (Fossil also omits this one. But remember - this is a talk about Git and the future of open-source, not a talk about Fossil.) (6) Simplified user interface. Git has the user interface that everybody loves to hate. Nobody except the most shrill Git partisan thinks that Git's user interface is good. How to make it better? Start by removing or at least hiding the staging area. (Readers: please offer other suggestions on how to improve the Git interface. Incompatible change ideas are welcomed.) (7) Need a "git all" command analogous to "fossil all" (8) Improved reporting for better situational awareness, in order to better serve the needs of agile programming. Start with a built-in "git serve" command, analogous to "hg serve" and/or "fossil serve". (I will argue that "fossil serve" works way better than "hg serve" though I would love to hear contrary views from mercurial advocates.) Also needed is the ability to display a timeline of changes to individual files. (9) New low-level Object format for Git. One that is consistent, is utf8 text (not binary), easily read by humans and parsed by programs, and where the SHA1 hash assigned to files in the repository really is a SHA1 hash of the file. -- D. Richard Hipp d...@sqlite.org _______________________________________________ fossil-dev mailing list fossil-dev@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
