9 ms·
It is true that Git can be used in a fairly simple way, although it is still significantly more complex than RCS. RCS has the whopping total of nine commands,
by NumberSix 12y ago
It is true that Git can be used in a fairly simple way, although it is still significantly more complex than RCS. RCS has the whopping total of nine commands, admittedly with various options and subcommands. $git --help yields a list of twenty-one commonly used commands out of the 148.
However, in practice, Git is being used in rather complex ways that are error prone and often lead to using other commands than the twenty-one "commonly used" Git commands such as git reflog, cherry-pick and others not in the "commonly used" list.
I have seen people combine a large number of changes into a single commit using Git's interactive rebase. The actual history remains in a local "private" branch on someone's computer. If it later turns out there was a bug introduced in this rebased mega-commit, it may be impossible to find the actual history and localize the actual change that caused the problem.
Even with access to the local repository, the actual changes may be found only in a feature or fix side branch with a cryptic name, one of hundreds generated using the lightweight branching in Git. There is no simple linear history of the changes with rebasing.
git reflog, in principle, gives a complete history but it is a confusing log of everything done and the information stored in it has an expiration time, which defaults to 90 days.
--expire=<time>
Entries older than this time are pruned. Without the option it is taken from configuration gc.reflogExpire, which in turn defaults to 90 days. --expire=all prunes entries regardless of their age; --expire=never turns off pruning of reachable entries (but see --expire-unreachable).
The obvious question from a usability perspective is: if twenty-one commands are all you really need, why confuse users with 148?
Actually, I got an astonishing 165 git commands using
$ git help -a
with Git version 1.7.9 on Cygwin
versus nine (9) RCS commands.
Bit by Git
- danieldk 12y agoIt is true that Git can be used in a fairly simple way, although it is still significantly more complex than RCS. What's the point? RCS is not fit for distributed workflows/projects. Once you start to work in such a fashion, you want multiple remotes, tracking branches, rebasing (if only to make submitted patches as clean as possible), security/consistency per SHA hashes, etc. This simply implies more complexity and commands. Sure, git could be simpler, some argue that Mercurial is easier. But RCS is definitely not the program you want to compare git with.
- NumberSix 12y agoMy point is the user interface, the command line interface, should be really simple, not much more than RCS's nine commands. Any necessary complexity should be hidden from the software developer so he or she can focus on developing the software and getting it working as quickly and effectively as possible. There are many examples of simple user interfaces layered on top of very complex programs and algorithms. Media players usually have a very simple GUI with a PLAY/STOP/PAUSE buttons and a volume control. Audio/video codecs, display drivers and so forth are extraordinarily complex but ideally the end user should not need to worry about this at all. Many of the Git GUI tools like sourcetree are an attempt to address this usability problem with the Git command line interface. Bit by Git