EasyGit [Was: Re: my git problem]

["Elijah Newren" <newren@gmail.com>]

On Thu, May 1, 2008 at 12:01 AM, Carl Worth <cworth@cworth.org> wrote:
>  Or maybe go Elijah's route and invent a new top-level command name in
>  which issues like this can get fixed. (I've been lukewarm on the idea
>  after watching the cogito attempt eventually be abandoned. I'd really
>  much rather see Elijah's ideas get pushed down into git itself for the
>  most part. But it's tough when backwards-compatibility prevents fixing
>  some things that are obviously confusing people.)

Except my route really doesn't fix things like this since I also
pushed for backwards compatibility.  You'll note that Havoc used
EasyGit and Git interchangably (both in his description and probably
on his projects), since all I've really done so far in EasyGit is
* provide built-in tutorial-oriented documentation
* check for common user mistakes and warn about them
* add subcommand options in a way that breaks up the near cylic
knowledge dependence of git subcommands so that they can be learned in
a layered/hierarchical fashion
* add some gratuitous svn-compatibility commands to ease the
transition for svn users

I agree that it would be nice to get this stuff (other than the last
point that likely doesn't make sense for git-core) into git
itself...if the community wants it.  Starting as a separate project
simply allowed me to make mistakes and figure out what works; I've
seen lots of proposals in the past for fixing up git and lots of them
end up breaking special use cases -- I've had a number of those myself
in EasyGit (and may still have some) and had to go back and fix them
up or find other solutions.

Also, as Havoc pointed out pretty clearly, what I've done in eg is
helpful for people getting started but there's a lot more
learnability/usability issues that need to be addressed.  I thought it
made more sense to address those first, so that's my next step.

Elijah