{"thread":{"id":"13352","subject":"EasyGit [Was: Re: my git problem]","startedAt":"2008-05-02T11:41:45Z","lastAt":"2008-06-30T16:23:10Z","messageCount":4,"participants":["Elijah Newren","Christian Couder","Sean Kelley"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"75822","messageId":"51419b2c0805020441l7a52f9d2q6bfc8eb4e18e4e7e@mail.gmail.com","threadId":"13352","inReplyTo":null,"subject":"EasyGit [Was: Re: my git problem]","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2008-05-02T11:41:45Z","receivedAt":"2008-05-02T11:41:45Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Thu, May 1, 2008 at 12:01 AM, Carl Worth <cworth@cworth.org> wrote:\n>  Or maybe go Elijah's route and invent a new top-level command name in\n>  which issues like this can get fixed. (I've been lukewarm on the idea\n>  after watching the cogito attempt eventually be abandoned. I'd really\n>  much rather see Elijah's ideas get pushed down into git itself for the\n>  most part. But it's tough when backwards-compatibility prevents fixing\n>  some things that are obviously confusing people.)\n\nExcept my route really doesn't fix things like this since I also\npushed for backwards compatibility.  You'll note that Havoc used\nEasyGit and Git interchangably (both in his description and probably\non his projects), since all I've really done so far in EasyGit is\n* provide built-in tutorial-oriented documentation\n* check for common user mistakes and warn about them\n* add subcommand options in a way that breaks up the near cylic\nknowledge dependence of git subcommands so that they can be learned in\na layered/hierarchical fashion\n* add some gratuitous svn-compatibility commands to ease the\ntransition for svn users\n\nI agree that it would be nice to get this stuff (other than the last\npoint that likely doesn't make sense for git-core) into git\nitself...if the community wants it.  Starting as a separate project\nsimply allowed me to make mistakes and figure out what works; I've\nseen lots of proposals in the past for fixing up git and lots of them\nend up breaking special use cases -- I've had a number of those myself\nin EasyGit (and may still have some) and had to go back and fix them\nup or find other solutions.\n\nAlso, as Havoc pointed out pretty clearly, what I've done in eg is\nhelpful for people getting started but there's a lot more\nlearnability/usability issues that need to be addressed.  I thought it\nmade more sense to address those first, so that's my next step.\n\nElijah\n"},{"id":"75824","messageId":"51419b2c0805020454p144698e4l843e8edab00ddeb7@mail.gmail.com","threadId":"13352","inReplyTo":"51419b2c0805020441l7a52f9d2q6bfc8eb4e18e4e7e@mail.gmail.com","subject":"Re: EasyGit [Was: Re: my git problem]","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2008-05-02T11:54:04Z","receivedAt":"2008-05-02T11:54:04Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Fri, May 2, 2008 at 5:41 AM, Elijah Newren <newren@gmail.com> wrote:\n> ... all I've really done so far in EasyGit is\n>  * provide built-in tutorial-oriented documentation\n>  * check for common user mistakes and warn about them\n>  * add subcommand options in a way that breaks up the near cylic\n>  knowledge dependence of git subcommands so that they can be learned in\n>  a layered/hierarchical fashion\n>  * add some gratuitous svn-compatibility commands to ease the\n>  transition for svn users\n\nI had typed up an explanation of what EasyGit is and does in more\ndetail and was going to wait to send it until I resolved some of the\nissues Havoc brought up, but maybe it makes sense to send that out\nnow.  So, here it is:\n\n\nEasyGit (eg) is a single-file script/porcelain that looks and feels like\ncore git.  In contrast to other simple-to-use porcelains, eg has all the\nsame capabilities as git (in particular, it does not remove the index) and\nuses the same general syntax as core git.  Eg primarily reduces the\nlearning curve associated with git and prevents common user errors.\n\nChanges:\n  Most of the changes in eg relative to git boil down to:\n    - plugging a large gap in git documentation (namely, providing a\n      tutorial-oriented built-in help system)\n    - warning about or preventing many common gotchas users run into with\n      git\n    - enabling users to learn in a layered fashion\n  A detailed explanation of the differences, rationale for the changes in\n  eg, and even arguments against some of the changes I made in eg can be\n  found at\n    http://www.gnome.org/~newren/eg/git-eg-differences.html\n\nSaving cvs/svn users:\n  EasyGit also looks and feels like svn on the most common subset of\n  functionality used in the two systems, mostly due to the addition of a\n  number of gratuitous svn-compatibility commands (such as cat, resolved,\n  update).  cvs and svn users may be interested in the detailed comparison\n  at\n    http://www.gnome.org/~newren/eg/git-for-svn-users.html\n\nTrying it:\n  I believe new users will be able to learn git faster by first using eg,\n  than by starting with git directly.  Switching between using eg and git\n  on the same repositories is considered perfectly normal.  There are a\n  couple aids to assist users in switching back and forth between eg and\n  git:\n    - Each help page has a section for listing any differences between eg\n      and git.\n    - Users can run\n        eg --translate ARGS...\n      to see what git command(s) would be run by\n        eg ARGS...\n      without actually running them.\n\nGoals for eg:\n  Git has obtained a reputation for being difficult to learn.  I wanted to\n  prove that a porcelain could be written which\n    1) was easy to learn\n    2) retained all the functionality in git\n    3) does not hinder the workflows of longtime git users and does not\n       require them to relearn the UI\n  Feedback from early adopters suggest that I have made good progress\n  towards achieving the first two goals; I do not have enough feedback\n  to determine whether I have done well with the last one.\n\n  I would like to see the parts of eg that the community likes\n  incorporated into git core.  I do not know which changes would be wanted\n  or welcome, and it may turn out that some of my changes show ignorance\n  of certain aspects of git (some such cases have previously been\n  uncovered already...and fixed).  But the discussion can't hurt, and a\n  number of the solutions I used in eg I have not found in searches of\n  previous discussions in the archives.\n\n\nElijah\n"},{"id":"76005","messageId":"200805041200.46099.chriscool@tuxfamily.org","threadId":"13352","inReplyTo":"51419b2c0805020454p144698e4l843e8edab00ddeb7@mail.gmail.com","subject":"Re: EasyGit [Was: Re: my git problem]","fromName":"Christian Couder","fromEmail":"chriscool@tuxfamily.org","sentAt":"2008-05-04T10:00:45Z","receivedAt":"2008-05-04T10:00:45Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"Le vendredi 2 mai 2008, Elijah Newren a écrit :\n>\n> EasyGit (eg) is a single-file script/porcelain that looks and feels like\n> core git.  In contrast to other simple-to-use porcelains, eg has all the\n> same capabilities as git (in particular, it does not remove the index)\n> and uses the same general syntax as core git.  Eg primarily reduces the\n> learning curve associated with git and prevents common user errors.\n>\n> Changes:\n>   Most of the changes in eg relative to git boil down to:\n>     - plugging a large gap in git documentation (namely, providing a\n>       tutorial-oriented built-in help system)\n\nI had a look at it. And I have a few comments that I prefixed with '#' \nbelow.\n\n$ eg help\n[...]\nTime saving commands\n  eg bisect     Find the change that introduced a bug by binary search\n[...]\n\n# What did they do to my beloved bisect? I need to have a look.\n\n$ eg help bisect\nSorry, bisect is not overridden or modified for eg, and no\nhelp has been written for it.  If you're feeling brave, you may\nwant to try running 'git help bisect'.\n\n# So they did nothing to it. Good ;-)\n# But then why don't they ask people to use \"git bisect\" directly instead\n# of \"eg bisect\" ?\n#\n# And they point to \"git help bisect\", good point.\n# No need to \"feel brave\" to look at \"git help bisect\" though, because I\n# think it is quite good. But I guess this is a generic message aimed at\n# other commands. \n\n$ eg help clone\n[...]\nSee also\n  Run 'man git-clone' for a comprehensive list of options available.\n  eg clone is designed to accept the same options as git clone, and\n  with the same meanings unless specified otherwise in the above\n  \"Differences\" section.\n\n# The output is longer than my terminal's 41 lines so I don't see its top\n# because there is no paging. \n# And why ask people to use \"man git-clone\" here, instead of \"git help\n# clone\" ?\n\n$ git clone -h\n[...]\n\n# \"git clone -h\" show more options in 18 lines only, but no examples\n# and no description.\n#\n# I am not sure that the \"Differences from git clone\" part from \"eg help\n# clone\" is really usefull for beginners.\n\n$ eg changes --details\n[...]\n\n# Very long output but it's paged.\n\n$ eg help help\n[...]\nDifferences from git help:\n  eg help uses its own help system, ignoring the one from git help...except\n  that eg help will call git help if asked for help on a subcommand it does\n  not recognize.\n\n  \"git help COMMAND\" simply calls \"man git-COMMAND\".  The git man pages are\n  really nice for people who are experts with git; they are comprehensive\n  and detailed.\n\n# It's not true that \"eg help will call git help if asked for help on a\n# subcommand it does not recognize\", it only display the same message as\n# for \"eg help bisect\" above.\n# \n# Also it's not exactly true that '\"git help COMMAND\" simply calls \"man\n# git-COMMAND\". If you use \"git help -w COMMAND\" or if you have\n# the \"help.format\" set to \"web\", you get a HTML man page opened in a new\n# tab in firefox (or something like that).\n#\n# And why not pointing to \"git COMMAND -h\" too, as it should give a \"long\n# usage\" string that is often usefull and easier to use as the man page ? \n\n[...]\n>\n>   I would like to see the parts of eg that the community likes\n>   incorporated into git core.  I do not know which changes would be\n> wanted or welcome, and it may turn out that some of my changes show\n> ignorance of certain aspects of git (some such cases have previously been\n> uncovered already...and fixed).  But the discussion can't hurt, and a\n> number of the solutions I used in eg I have not found in searches of\n> previous discussions in the archives.\n\nWhat I like about the built-in help system in eg is that there are lots of \nexamples displayed. I think the git man pages are somewhat lacking in this \narea. (Some examples are still using the \"git-COMMAND\" syntax for example.) \n\nThe built-in help text in eg also seems simpler and easier to understand, \nbut it may be because there are fewer options and simpler commands to \nexplain.\n\nSo here are some things that could be done to improve git help system:\n\n- find a way to make users know that they can get long usage help using \"git \nCOMMAND -h\"\n- find a way to display some examples on the command line without the full \nman page\n- add and improve examples in man pages\n- add some simpler explanations to man pages and perhaps move more complex \nexplanations to a \"DETAILED DESCRIPTION\" part of the man page\n- improve man pages in other ways\n\nThanks,\nChristian.\n"},{"id":"81757","messageId":"89b129c60806300923w232cb3e2s5a46790475f7afec@mail.gmail.com","threadId":"13352","inReplyTo":"51419b2c0805020441l7a52f9d2q6bfc8eb4e18e4e7e@mail.gmail.com","subject":"Re: EasyGit [Was: Re: my git problem]","fromName":"Sean Kelley","fromEmail":"sean.v.kelley@gmail.com","sentAt":"2008-06-30T16:23:10Z","receivedAt":"2008-06-30T16:23:10Z","isPatch":false,"sender":{"key":"sean.v.kelley@gmail.com","avatar":null},"body":"On Fri, May 2, 2008 at 6:41 AM, Elijah Newren <newren@gmail.com> wrote:\n> On Thu, May 1, 2008 at 12:01 AM, Carl Worth <cworth@cworth.org> wrote:\n>>  Or maybe go Elijah's route and invent a new top-level command name in\n>>  which issues like this can get fixed. (I've been lukewarm on the idea\n>>  after watching the cogito attempt eventually be abandoned. I'd really\n>>  much rather see Elijah's ideas get pushed down into git itself for the\n>>  most part. But it's tough when backwards-compatibility prevents fixing\n>>  some things that are obviously confusing people.)\n>\n> Except my route really doesn't fix things like this since I also\n> pushed for backwards compatibility.  You'll note that Havoc used\n> EasyGit and Git interchangably (both in his description and probably\n> on his projects), since all I've really done so far in EasyGit is\n> * provide built-in tutorial-oriented documentation\n> * check for common user mistakes and warn about them\n> * add subcommand options in a way that breaks up the near cylic\n> knowledge dependence of git subcommands so that they can be learned in\n> a layered/hierarchical fashion\n> * add some gratuitous svn-compatibility commands to ease the\n> transition for svn users\n>\n> I agree that it would be nice to get this stuff (other than the last\n> point that likely doesn't make sense for git-core) into git\n> itself...if the community wants it.\n\nI agree with Carl in that my fear is that this will go the same route\nas cogito if it doesn't get into git itself.  We use mercurial rather\nextensively at garmin on my teams. There are a number of items I\nreally miss from git.  For the most part I believe Carl has enumerated\nin other threads the sort of items that cause the greatest issues with\nusability.\n\nI think you addressed the first steps rather well with eg.\n\nSean\n"}]}