git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Sean Kelley" <sean.v.kelley@gmail.com>
To: "Elijah Newren" <newren@gmail.com>
Cc: "Carl Worth" <cworth@cworth.org>,
	"Linus Torvalds" <torvalds@linux-foundation.org>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	git@vger.kernel.org, "Havoc Pennington" <hp@pobox.com>
Subject: Re: EasyGit [Was: Re: my git problem]
Date: Mon, 30 Jun 2008 11:23:10 -0500	[thread overview]
Message-ID: <89b129c60806300923w232cb3e2s5a46790475f7afec@mail.gmail.com> (raw)
In-Reply-To: <51419b2c0805020441l7a52f9d2q6bfc8eb4e18e4e7e@mail.gmail.com>

On Fri, May 2, 2008 at 6:41 AM, Elijah Newren <newren@gmail.com> wrote:
> 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.

I agree with Carl in that my fear is that this will go the same route
as cogito if it doesn't get into git itself.  We use mercurial rather
extensively at garmin on my teams. There are a number of items I
really miss from git.  For the most part I believe Carl has enumerated
in other threads the sort of items that cause the greatest issues with
usability.

I think you addressed the first steps rather well with eg.

Sean

      parent reply	other threads:[~2008-06-30 16:24 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-02 11:41 EasyGit [Was: Re: my git problem] Elijah Newren
2008-05-02 11:54 ` Elijah Newren
2008-05-04 10:00   ` Christian Couder
2008-06-30 16:23 ` Sean Kelley [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=89b129c60806300923w232cb3e2s5a46790475f7afec@mail.gmail.com \
    --to=sean.v.kelley@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=cworth@cworth.org \
    --cc=git@vger.kernel.org \
    --cc=hp@pobox.com \
    --cc=newren@gmail.com \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).