Theodore Ts'o wrote: > On Sat, Jul 03, 2021 at 01:16:16PM -0500, Felipe Contreras wrote: > > Atharva Raykar wrote: > > > I can imagine aliases like 'co' only adding to the overload of > > > information if an instructor is not careful. FWIW, I have never seen a new > > > user complain about the length of the typing, it's usually with the plethora > > > of unintelligible (to them) options that each command has when they open the > > > Git man pages, which adds more fear. > > > > This is one of the reasons I suggested to split git into two binaries: > > git for normal users, and git-tool for all the plumbing not many humans > > use. > > It might be that the answer for the problem Atharva has described > would be for someone so include to create a new front-end to git --- > call it "sg", for simplified git", or "gt" for git tool (different > from the "git-tool suggested by Felipe), etc. > > It could be an extremely opinionated subset of git's functionality; > for example, it could be one where the index is completely hidden from > the user, so you never need to type "sg add" when modifying a file, > but only when adding a new file to be under source code management > (e.g., that "sg commit" would effectively imply "git add -u ; git > commit"), and so on. Since the index doesn't conceptually exist in > the sg interface, then "sg reset" would only have the meaning of "git > reset --hard", etc. > > By definition this simplified front-end to git would have a subset of > the functionality of "full git", but that's OK. The whole goal would > be to make something super newbie-friendly --- the equivalent of a > "Mac OS-like" interface, that perhaps doesn't have the power of > someone who opens up a shell and uses tools like awk or perl, but is > good enough "for the rest of the human race". > > Note that this doesn't have to be an official "git" ccommunity > initiative; anyone could try to create such one of these things (and I > believe a few things exist already). > > Making it a non-goal that this "user friendly" front end doesn't have > to have the full functionality of git, and its main goal is to allow > the use of different user interface design choices made by git, might > be much simpler than trying to change git, which would require having > the argument over which functionality is used by "normal users", and > which features should be exiled to "git-pull" as being "fringe" > features. I think there's some value in that idea but that doesn't solve the same problem my suggestion solves. Basically there's too many commands in `man git`. Splitting the git binary would allow us to only put the important commands in `man git`. I think having too many commands overwhelms many newcomers, because they don't know which it's important for them to learn and which are basically noise. -- Felipe Contreras
