Re: The git spring cleanup challenge completion

> 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.