Re: EasyGit Integration

From: Elijah Newren <newren@gmail.com>
Date: Jun 9, 2009, 22:00 UTC
Message-ID: <51419b2c0906091500q6aaff225q42bd79e6349a1143@mail.gmail.com>
In-Reply-To: <d411cc4a0906091159r51e7d16t4d66c6225322fb60@mail.gmail.com>

Hi,

On Tue, Jun 9, 2009 at 12:59 PM, Scott Chacon<schacon@gmail.com> wrote:

> Hey all,
>
> I have been playing with the EasyGit project lately and I have been
> really impressed.

Thanks for bringing this up. I should have done better at proposing some of these changes upstream...

> * breaks the various things that 'checkout' does into separate
> commands - moves 'revert' to doing what 'checkout -- path' does, moves
> current 'revert' to 'cherry-pick --revert' (which someone mentioned
> was a good idea at the last GitTogether), and adds 'unstage' for

As a side note, the mapping from eg revert to git commands is not so
simple; you'll miss a lot of cases if you were to make a simple alias.
 :-)

<snip a highlight of some changes in eg>

I'll note that you can run 'eg changes --details' to get a (hopefully up-to-date and) complete list...

> Some other things that might be nice:
>
> * 'git backout' for 'git reset HEAD^'

May cause confusion for mercurial users (hg backout == current git revert). I don't have a better proposal, though. 'uncommit'?

Also, a consistency proposal that I have not yet gotten to
implementing in eg; It'd be nice to add more consistency with these
commands:
 - continue incomplete am: git am --resolved
 - continue incomplete rebase: git rebase --continue
 - continue incomplete merge: git commit
so that it looks like this (while still allowing the old ways for
backward compatibility):
 => continue incomplete am: git am --continue
 => continue incomplete rebase: git rebase --continue
 => continue incomplete merge: git merge --continue   (or is this
going overboard?)

And to change this:
 - abort incomplete am: git am --abort
 - abort incomplete bisect: git bisect reset
 - abort incomplete merge: git reset --hard HEAD
 - abort incomplete rebase: git rebase --abort
so that it looks like this (again still allowing old ways):
 => abort incomplete am: git am --abort
 => abort incomplete bisect: git bisect --abort
 => abort incomplete merge: git merge --abort
 => abort incomplete rebase: git rebase --abort

Show 12 quoted lines

> These things may seem pretty simple and even sort of stupid if you're
> used to Git as we are - most of them you can just setup an alias
> pretty easily, but you would be amazed at how many people go nuts
> because of this stuff.  If these simple things were in as defaults,
> sooo many of the remaining 'git is hard and obtuse' arguments would
> become obsolete.  'checkout', 'add' and 'reset' seem to be where
> people have the most difficulty, due to their overloading.
>
> Does this resonate with anyone else?  Does 1.7 seem like a good goal
> for amending some of these things?  Completely redefining 'revert'
> seems like the only backward incompatible change - everything else is
> just wrappers and whatnot, I think.

Mostly just wrappers, yes. There are two other big incompatible changes, both to push: (1) 'eg push' is basically hardcoded to do what push.default=tracking now does (although now that push.default exists, I'm considering dropping this change in eg), and (2) eg push will try to check whether the remote repository is bare and deny the push unless one of the arguments is a refspec that has a ':' character in it (i.e. a push-side check, rather than git's recent receive-side check; having both probably doesn't make sense, so it's another thing I'm reconsidering).

Also, I wondered whether others would consider the different defaults for commit & diff to be a big backward incompatible change, though the fact that you didn't seem to notice it and lots of others don't either suggest it's not that big (for experienced users). There are also more minor changes to the defaults of bundle, log, and status, but those are innocuous enough that they hardly qualify as backward incompatible.

Thanks, Elijah