EasyGit Integration

EasyGit Integration

[Scott Chacon]

Hey all,

I have been playing with the EasyGit project lately and I have been
really impressed.  I looked back to the last announcement here and the
conversation didn't really go anywhere, sadly.  I thought it might be
nice to adopt or at least consider a number of the design decisions
they made in modifying the defaults and commands available.  Perhaps
as a 1.7 goal or something?  I like it because it addresses a lot of
the issues that I hear from beginning users:

* 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
'reset HEAD file'.  also adds a '-s' option to 'branch' to switch to
the branch after you create it, which many people expect rather than
'checkout -b'.

* adds 'git resolved' for 'git add', which I hear all the time as
being confusing

* adds 'git publish' for creating a bare repo from your current repo
and scp/rsync-ing it to a server (which is nice if you're not using
GitHub/repo.or.cz where remote repo seeding is easier)

* adds 'git info' which shows a bunch of basic information about the
repo, which is actually pretty cool

* more verbose and easily scannable default help output - groups the
commands into categories, etc.

Some other things that might be nice:

* 'git backout' for 'git reset HEAD^'

* 'git push origin --delete <branch>' for 'git push origin :branch'

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.

Thanks,
Scott

Re: EasyGit Integration

[Nicolas Pitre]

On Tue, 9 Jun 2009, Scott Chacon wrote:

> Hey all,
> 
> I have been playing with the EasyGit project lately and I have been
> really impressed.  I looked back to the last announcement here and the
> conversation didn't really go anywhere, sadly.  I thought it might be
> nice to adopt or at least consider a number of the design decisions
> they made in modifying the defaults and commands available.  Perhaps
> as a 1.7 goal or something?  I like it because it addresses a lot of
> the issues that I hear from beginning users:
[...]
> 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.

Completely agreed.

This is indeed refreshing to see some of the git UI warts being 
addressed by people who simply aren't too used to them like I am.

And like you said, most of those changes don't create any 
incompatibilities and therefore could be fed back _piecemeal_ into the 
main git repository today without even requiring a major version bump.


Nicolas

Re: EasyGit Integration

[Avery Pennarun]

On Tue, Jun 9, 2009 at 2:59 PM, Scott Chacon<schacon@gmail.com> wrote:
> * 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
> 'reset HEAD file'.  also adds a '-s' option to 'branch' to switch to
> the branch after you create it, which many people expect rather than
> 'checkout -b'.

This would definitely make it easier to explain things to svn users.
To be honest, I'm not convinced svn's use of the word "revert" is
really right, though.  Git's isn't *really* right either, since it
actually makes a new commit, it doesn't remove the old one like it
sounds like it does.  Maybe 'reverse' would be a better name for what
git does, and we should just introduce another word for what svn does.
 (With CVS, you just deleted the file and then did a checkout/update
on it again, which made sense to me.  That works in git too.)

Crazy idea: we could actually make 'git revert' do both: given a
commit, it applies the reverse as it does now.  Given filenames, it
simply brings them back to HEAD.  But maybe that's too crazy.

> * adds 'git resolved' for 'git add', which I hear all the time as
> being confusing

This one doesn't really do it for me.  svn's need to "resolve" a file
after removing its conflicts always annoyed me.  Look, you can see
I've screwed around with the file.  The file contains no more
conflicts.  It's resolved, already!

Maybe it's heresy, but I really liked CVS's way of dealing with this:
if the file still has conflict markers in it, it's not resolved.  If
it doesn't, then it's resolved.  Very hard to mess up.  And I've
definitely messed up (and known other people to mess up) with both
svn's method and git's method, both of which allow you to commit files
with conflict markers without getting warned.

> * adds 'git publish' for creating a bare repo from your current repo
> and scp/rsync-ing it to a server (which is nice if you're not using
> GitHub/repo.or.cz where remote repo seeding is easier)

Very cool, and this has been seriously hard to explain to people.  I'm
not even sure there *is* a good way to do this without running a
series of several commands.

> * adds 'git info' which shows a bunch of basic information about the
> repo, which is actually pretty cool

Less important to me, but sounds fine just due to svn compatibility.

> * 'git push origin --delete <branch>' for 'git push origin :branch'

This would help a lot of people too, I think.  Although some might
argue that "helping" them to delete branches is maybe not a great
idea.

Have fun,

Avery

Re: EasyGit Integration

[Björn Steinbrink]

On 2009.06.09 15:52:46 -0400, Avery Pennarun wrote:
> On Tue, Jun 9, 2009 at 2:59 PM, Scott Chacon<schacon@gmail.com> wrote:
> > * 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
> > 'reset HEAD file'.  also adds a '-s' option to 'branch' to switch to
> > the branch after you create it, which many people expect rather than
> > 'checkout -b'.
> 
> This would definitely make it easier to explain things to svn users.
> To be honest, I'm not convinced svn's use of the word "revert" is
> really right, though.  Git's isn't *really* right either, since it
> actually makes a new commit, it doesn't remove the old one like it
> sounds like it does.  Maybe 'reverse' would be a better name for what
> git does, and we should just introduce another word for what svn does.
>  (With CVS, you just deleted the file and then did a checkout/update
> on it again, which made sense to me.  That works in git too.)
> 
> Crazy idea: we could actually make 'git revert' do both: given a
> commit, it applies the reverse as it does now.  Given filenames, it
> simply brings them back to HEAD.  But maybe that's too crazy.

Doesn't seem that crazy to me. But maybe a bit problematic if you want
to support both, "git checkout -- ." and "git checkout HEAD -- .". And
adding DWIMmery there seems dangerous, as in:

git revert == git checkout -- .

git revert HEAD ==
  no uncommitted changes = revert commit HEAD
  uncommitted changes = revert to HEAD

Björn

Re: EasyGit Integration

[Avery Pennarun]

2009/6/9 Björn Steinbrink <B.Steinbrink@gmx.de>:
> On 2009.06.09 15:52:46 -0400, Avery Pennarun wrote:
>> To be honest, I'm not convinced svn's use of the word "revert" is
>> really right, though.  Git's isn't *really* right either, since it
>> actually makes a new commit, it doesn't remove the old one like it
>> sounds like it does.  Maybe 'reverse' would be a better name for what
>> git does, and we should just introduce another word for what svn does.
>>  (With CVS, you just deleted the file and then did a checkout/update
>> on it again, which made sense to me.  That works in git too.)
>>
>> Crazy idea: we could actually make 'git revert' do both: given a
>> commit, it applies the reverse as it does now.  Given filenames, it
>> simply brings them back to HEAD.  But maybe that's too crazy.
>
> Doesn't seem that crazy to me. But maybe a bit problematic if you want
> to support both, "git checkout -- ." and "git checkout HEAD -- .". And
> adding DWIMmery there seems dangerous, as in:
>
> git revert == git checkout -- .
>
> git revert HEAD ==
>  no uncommitted changes = revert commit HEAD
>  uncommitted changes = revert to HEAD

Well, that's what I meant by "crazy" :)

Since so many of the other suggestions in eg are so simple and
non-conflicting, perhaps it's best to drop this branch of discussion
until the non-controversial bits are adopted.  It would be bad to lose
other great improvements just because this one command is
problematic...

Have fun,

Avery

Re: EasyGit Integration

[Björn Steinbrink]

On 2009.06.09 16:42:33 -0400, Avery Pennarun wrote:
> 2009/6/9 Björn Steinbrink <B.Steinbrink@gmx.de>:
> > On 2009.06.09 15:52:46 -0400, Avery Pennarun wrote:
> >> To be honest, I'm not convinced svn's use of the word "revert" is
> >> really right, though.  Git's isn't *really* right either, since it
> >> actually makes a new commit, it doesn't remove the old one like it
> >> sounds like it does.  Maybe 'reverse' would be a better name for what
> >> git does, and we should just introduce another word for what svn does.
> >>  (With CVS, you just deleted the file and then did a checkout/update
> >> on it again, which made sense to me.  That works in git too.)
> >>
> >> Crazy idea: we could actually make 'git revert' do both: given a
> >> commit, it applies the reverse as it does now.  Given filenames, it
> >> simply brings them back to HEAD.  But maybe that's too crazy.
> >
> > Doesn't seem that crazy to me. But maybe a bit problematic if you want
> > to support both, "git checkout -- ." and "git checkout HEAD -- .". And
> > adding DWIMmery there seems dangerous, as in:
> >
> > git revert == git checkout -- .
> >
> > git revert HEAD ==
> >  no uncommitted changes = revert commit HEAD
> >  uncommitted changes = revert to HEAD
> 
> Well, that's what I meant by "crazy" :)

OK, thinking about it, I really dislike the idea of "revert --since",
as that is IMHO better thought of as "get the old version back", and for
"get something out of the repo" we have checkout. That would leave us
with "revert changes from a commit" and "revert uncommitted/unstaged
changes". For that "limited" thing, I could live with:

git revert <commit> # As is
git revert --unstaged # git checkout -- 
git revert --uncommitted # git checkout HEAD -- / git rm --cached

IOW: Mode of operation is chosen by a flag, which has a meaning that is
somewhat similar to --cached for diff/rm, it chooses what to use as the
source for the operation. And as at least "revert --uncommitted" isn't
100% the same as "checkout HEAD --", I think the overlap that we'd have
with a small subset of the checkout functionality might be ok.

Björn

Re: EasyGit Integration

[Elijah Newren]

2009/6/9 Björn Steinbrink <B.Steinbrink@gmx.de>:
>> Crazy idea: we could actually make 'git revert' do both: given a
>> commit, it applies the reverse as it does now.  Given filenames, it
>> simply brings them back to HEAD.  But maybe that's too crazy.

Probably too crazy (too much potential for confusion), but an
interesting thing about the way eg revert was written is that any
valid git revert command passed to eg revert is invalid syntax, so I
can print the simple error message:
  If you are used to git revert, try 'eg cherry-pick -R <ARGS>'...

That prevents accidental misuse and misunderstandings, such as these:

> Doesn't seem that crazy to me. But maybe a bit problematic if you want
> to support both, "git checkout -- ." and "git checkout HEAD -- .". And
> adding DWIMmery there seems dangerous, as in:
>
> git revert == git checkout -- .
>
> git revert HEAD ==
>  no uncommitted changes = revert commit HEAD
>  uncommitted changes = revert to HEAD

I was thinking that if people had too much heartburn over changing the
meaning of revert from "revert-commit" to "revert-edits", then we
could always submit the eg revert functionality as git-revert-edits.

Re: EasyGit Integration

[Miles Bader]

Avery Pennarun <apenwarr@gmail.com> writes:
> This would definitely make it easier to explain things to svn users.
> To be honest, I'm not convinced svn's use of the word "revert" is
> really right, though.  Git's isn't *really* right either, since it
> actually makes a new commit, it doesn't remove the old one like it
> sounds like it does.

I think both definitions are quite reasonable.

The sense in which git uses the word -- "make a change reversing an
earlier change" -- is actually very common in programming.

-Miles

-- 
Would you like fries with that?

Re: EasyGit Integration

[Björn Steinbrink]

On 2009.06.09 11:59:08 -0700, Scott Chacon wrote:
> * breaks the various things that 'checkout' does into separate
> commands - moves 'revert' to doing what 'checkout -- path' does

Looking through the "eg revert" docs [1], I can't seem to find how you can
do "checkout -- path" with it at all. "eg revert foo" seems to be "git
checkout HEAD -- foo". The "eg revert" looks really confusing to me.
"eg revert --unstaged --in HEAD~8". Hu? Revert unstaged changes in
HEAD~8? Am I missing something?

Björn

[1] http://www.gnome.org/~newren/eg/documentation/revert.html

Re: EasyGit Integration

[Elijah Newren]

Hi,

2009/6/9 Björn Steinbrink <B.Steinbrink@gmx.de>:
> On 2009.06.09 11:59:08 -0700, Scott Chacon wrote:
>> * breaks the various things that 'checkout' does into separate
>> commands - moves 'revert' to doing what 'checkout -- path' does
>
> Looking through the "eg revert" docs [1], I can't seem to find how you can
> do "checkout -- path" with it at all. "eg revert foo" seems to be "git
> checkout HEAD -- foo".

If you want to revert only the unstaged changes to path:
  "checkout -- path" OR "revert --unstaged path"
If you want to revert both staged and unstaged changes to foo:
  "checkout HEAD -- foo" OR "revert foo"

> The "eg revert" looks really confusing to me.
> "eg revert --unstaged --in HEAD~8". Hu? Revert unstaged changes in
> HEAD~8? Am I missing something?

Hmm.  Bad ordering, I guess -- it's revert changes in HEAD~8 to the
working copy only (by default, revert tries to apply changes to both
the working copy and the index).  Yeah, it doesn't read very well.

I'm not sure I like having "--in" as part of revert, partially because
of this confusion (and partially because I don't think it's
implementation is correct anyway).  However, I do occasionally really
like being able to revert the change _to a single file_ made in some
previous commit, so I haven't removed it from eg (yet?).  *shrug*



Elijah

Re: EasyGit Integration

[Björn Steinbrink]

On 2009.06.09 14:40:33 -0600, Elijah Newren wrote:
> Hi,
> 
> 2009/6/9 Björn Steinbrink <B.Steinbrink@gmx.de>:
> > On 2009.06.09 11:59:08 -0700, Scott Chacon wrote:
> >> * breaks the various things that 'checkout' does into separate
> >> commands - moves 'revert' to doing what 'checkout -- path' does
> >
> > Looking through the "eg revert" docs [1], I can't seem to find how you can
> > do "checkout -- path" with it at all. "eg revert foo" seems to be "git
> > checkout HEAD -- foo".
> 
> If you want to revert only the unstaged changes to path:
>   "checkout -- path" OR "revert --unstaged path"
> If you want to revert both staged and unstaged changes to foo:
>   "checkout HEAD -- foo" OR "revert foo"

OK, so --unstaged doesn't just select the destination, but also the
source, unless you explicitly override it, right?

eg revert [--since HEAD] path
  ==> source: HEAD, destination: working tree, index

eg revert --unstaged path
  ==> source: index, destination: working tree

eg revert --unstaged --since HEAD path
  ==> source: HEAD, destination: working tree


> 
> > The "eg revert" looks really confusing to me.
> > "eg revert --unstaged --in HEAD~8". Hu? Revert unstaged changes in
> > HEAD~8? Am I missing something?
> 
> Hmm.  Bad ordering, I guess -- it's revert changes in HEAD~8 to the
> working copy only (by default, revert tries to apply changes to both
> the working copy and the index).  Yeah, it doesn't read very well.
> 
> I'm not sure I like having "--in" as part of revert, partially because
> of this confusion (and partially because I don't think it's
> implementation is correct anyway).  However, I do occasionally really
> like being able to revert the change _to a single file_ made in some
> previous commit, so I haven't removed it from eg (yet?).  *shrug*

I'm not sure that "--in" is the worst thing here. To me, --unstaged is
worse, because I apply the attribute "unstaged" to the changes to be
reverted. And that makes no sense when I supply a commit, a commit
cannot have unstaged changes. I guess that if --unstaged wasn't used to
select the destination, I might have come up with "eg revert --unstaged"
myself, just from seeing the options. But seeing that --unstaged can be
used with a commit confused me.

Björn

Re: EasyGit Integration

[Björn Steinbrink]

On 2009.06.09 11:59:08 -0700, Scott Chacon wrote:
> * adds 'git resolved' for 'git add', which I hear all the time as
> being confusing

Is "resolve" a plain alias, like "stage", or smart in deciding which
files it accepts? My gut feeling is that a plain alias might cause
trouble again when users get lazy and start to do "git resolve ." and
wonder why that adds new files.

Iff such a "resolve" command is added, it should IMHO only serve the
purpose of changing the status of index entries marked as "unstaged",
and do nothing else that "add" can do. When someone asks why "git add"
is used for telling git that a conflict was resolved, I can say that
"git add" means "add this to the things to be committed" and that that
implies that conflicts have been resolved (I like to describe "git add"
as "tell git that 'this is good to commit'"). So I can give some logical
explanation. But if someone would ask me why "git resolve" can add new
files, which never had a merge conflict, to the index, I'd be pretty
stumped.

Björn

Re: EasyGit Integration

[Junio C Hamano]

Björn Steinbrink <B.Steinbrink@gmx.de> writes:

> On 2009.06.09 11:59:08 -0700, Scott Chacon wrote:
>> * adds 'git resolved' for 'git add', which I hear all the time as
>> being confusing
>
> Is "resolve" a plain alias, like "stage", or smart in deciding which
> files it accepts? My gut feeling is that a plain alias might cause
> trouble again when users get lazy and start to do "git resolve ." and
> wonder why that adds new files.
>
> Iff such a "resolve" command is added, it should IMHO only serve the
> purpose of changing the status of index entries marked as "unstaged",
> and do nothing else that "add" can do.

Very good point (modulo s/unstaged/unmerged/ I think).

Re: EasyGit Integration

[Elijah Newren]

2009/6/9 Björn Steinbrink <B.Steinbrink@gmx.de>:
> On 2009.06.09 11:59:08 -0700, Scott Chacon wrote:
>> * adds 'git resolved' for 'git add', which I hear all the time as
>> being confusing
>
> Is "resolve" a plain alias, like "stage", or smart in deciding which
> files it accepts? My gut feeling is that a plain alias might cause
> trouble again when users get lazy and start to do "git resolve ." and
> wonder why that adds new files.

In eg it's currently a plain alias, but I like your arguments for
making it only handle unmerged entries.

> Iff such a "resolve" command is added, it should IMHO only serve the
> purpose of changing the status of index entries marked as "unstaged",
> and do nothing else that "add" can do. When someone asks why "git add"
> is used for telling git that a conflict was resolved, I can say that
> "git add" means "add this to the things to be committed" and that that
> implies that conflicts have been resolved (I like to describe "git add"
> as "tell git that 'this is good to commit'"). So I can give some logical
> explanation. But if someone would ask me why "git resolve" can add new
> files, which never had a merge conflict, to the index, I'd be pretty
> stumped.

Re: EasyGit Integration

[Elijah Newren]

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

> 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

Re: EasyGit Integration

[Matthieu Moy]

Elijah Newren <newren@gmail.com> writes:

>> Some other things that might be nice:
>>
>> * 'git backout' for 'git reset HEAD^'
>
> May cause confusion for mercurial users (hg backout == current git
> revert).

Yes, and a bit of consistency between the various (D)VCS would be good
(for regular-hg-users which are also occasional-git-users and so).

> I don't have a better proposal, though. 'uncommit'?

I like 'uncommit'. That's what bzr uses.

-- 
Matthieu

Re: EasyGit Integration

[Linus Torvalds]

On Tue, 9 Jun 2009, Scott Chacon wrote:
> 
> * breaks the various things that 'checkout' does into separate
> commands - moves 'revert' to doing what 'checkout -- path' does

No.

NAK on this one. 

The fact that some idiotic SVN usage exists is not an excuse to break 
long-standing git users. "revert" comes from bk, and quite frankly, I 
object _very_ strongly to taking naming from something that is very 
obviously the inferior system (SVN) over something very obviously superior 
(BK and git).

Feel free to add other "helper" aliases that are actually _new_ and have 
no pre-existing git meaning, but not things like this. Not breaking 
existing git usage just because somebody is too stupid and/or lazy to try 
to learn a new word.

		Linus

Re: EasyGit Integration

[Elijah Newren]

On Tue, Jun 9, 2009 at 4:14 PM, Linus
Torvalds<torvalds@linux-foundation.org> wrote:
> On Tue, 9 Jun 2009, Scott Chacon wrote:
>>
>> * breaks the various things that 'checkout' does into separate
>> commands - moves 'revert' to doing what 'checkout -- path' does
>
> No.
<snip>
> Feel free to add other "helper" aliases that are actually _new_ and have
> no pre-existing git meaning, but not things like this. Not breaking
> existing git usage just because somebody is too stupid and/or lazy to try
> to learn a new word.

Do you object to using 'revert' in the name of the new command or just
to having the new command take over the exact name 'revert'?  I'd like
to propose making the reverting of edits functionality available under
the command name 'revert-edits', while leaving the existing reverting
of commits functionality under 'revert', but I'm not sure if that
would run afoul of your objections as well.


Elijah

Re: EasyGit Integration

[Linus Torvalds]

On Tue, 9 Jun 2009, Elijah Newren wrote:
> 
> Do you object to using 'revert' in the name of the new command or just
> to having the new command take over the exact name 'revert'?

I object to changing existing meaning.

> I'd like to propose making the reverting of edits functionality 
> available under the command name 'revert-edits'

That's fine.

I also don't mind per se having the "git checkout" kind of semantics, 
where different kinds of arguments result in different kinds of behavior. 
I'm not convinced it's a wonderful design, but I would not object to

 - old behavior: revert the commit by creating an "anti-commit":

	git revert <cmit-name>

 - new extension: revert the state of the working tree to the HEAD:

	git revert [--] pathspec

which would kind of match the semantics of "git checkout" does.

So it's not that I object to "git revert" as a name. I just object to 
changing existing (and sane) semantics just for some silly person who 
thinks that git is just "SVN done right". 

Git is _soo_ much more than just that. People need to live with the fact 
that it's not just a SVN clone.

		Linus

Re: EasyGit Integration

[Mark Lodato]

I too would like to see some of the improved UI aspects of EasyGit
merged into git.


On Tue, Jun 9, 2009 at 6:40 PM, Linus
Torvalds<torvalds@linux-foundation.org> wrote:
> So it's not that I object to "git revert" as a name. I just object to
> changing existing (and sane) semantics just for some silly person who
> thinks that git is just "SVN done right".
>
> Git is _soo_ much more than just that. People need to live with the fact
> that it's not just a SVN clone.

I do not think "revert" to mean "checkout --" is just an SVN idiom.  I
have heard similar suggestions by people first learning git who have
never used SVN or CVS before.  To me, "revert" is a very natural name
for a command to undo changes in the working directory.  "Checkout,"
on the other hand, usually means to switch branches, which is
logically distinct from undoing changes in the working tree.  In fact,
if one tries to use "checkout" to switch a branch while there are
local changes, git will refuse!

At the same time, "revert" also is a fine name for making an inverse
commit, as revert currently does.  So perhaps overloading revert as
you suggest is a good idea.  It is wise, as you suggest, to keep
backwards compatibility for existing users.



Mark

Re: EasyGit Integration

[Miles Bader]

Linus Torvalds <torvalds@linux-foundation.org> writes:
> I'm not convinced it's a wonderful design, but I would not object to
>
>  - old behavior: revert the commit by creating an "anti-commit":
> 	git revert <cmit-name>
>  - new extension: revert the state of the working tree to the HEAD:
> 	git revert [--] pathspec
>
> which would kind of match the semantics of "git checkout" does.

That seems even more confusing, to _both_ svn users and git users...

The similar overloading of "checkout" (to have two completely different
meanings depending on whether a branch or pathname is specified) also
feels very awkward to me.

I sort of assumed that the "checkout -- pathname" form was added as a
sop to cvs/svn users, for which that's a very common idiom...

-Miles

-- 
In New York, most people don't have cars, so if you want to kill a person, you
have to take the subway to their house.  And sometimes on the way, the train
is delayed and you get impatient, so you have to kill someone on the subway.
  [George Carlin]

Re: EasyGit Integration

[Theodore Tso]

On Tue, Jun 09, 2009 at 03:40:35PM -0700, Linus Torvalds wrote:
> I also don't mind per se having the "git checkout" kind of semantics, 
> where different kinds of arguments result in different kinds of behavior. 
> I'm not convinced it's a wonderful design, but I would not object to
> 
>  - old behavior: revert the commit by creating an "anti-commit":
> 
> 	git revert <cmit-name>
> 
>  - new extension: revert the state of the working tree to the HEAD:
> 
> 	git revert [--] pathspec
> 
> which would kind of match the semantics of "git checkout" does.

My personal opinion is this kind of overloading is actually more
confusing than simply adding a new name, such as "git revert-file".
Of course, you can do that already using a git alias....  So IMHO the
best way of handling this issue is to have git tutorials use this as a
teachable moment, so people can create their own git alias for "git
checkout HEAD --".

   	       	      	   	   	   - Ted

Re: EasyGit Integration

[Linus Torvalds]

On Tue, 9 Jun 2009, Theodore Tso wrote:
> 
> My personal opinion is this kind of overloading is actually more
> confusing than simply adding a new name, such as "git revert-file".

I'd agree, except I think it actually worked pretty well in "git 
checkout". 

The alternative was to add yet another command for that, or to teach 
people about the internal commands we did have. Adding the capability for 
checkout to check out individual files - in addition to commits and 
branches - I think worked pretty well.

And "git checkout" in many ways is an even more complicated case, much 
more so than the suggested "git revert".

Now, I also happen to think that "git checkout [cmit] -- pathspec" is a 
much more _logical_ name for what the SVN people apparently call "revert", 
but hey, whatever. If SVN people feel happier about writing "git revert 
<pathspec>", then why not?

But I certainly won't argue very sternuously for adding that whole new 
"git revert [cmit] [--] <pathspec>" syntax. I can certainly live without 
it.  I don't think it would be a disaster, though.

		Linus

Re: EasyGit Integration

[Felipe Contreras]

On Wed, Jun 10, 2009 at 7:03 AM, Linus
Torvalds<torvalds@linux-foundation.org> wrote:
>
>
> On Tue, 9 Jun 2009, Theodore Tso wrote:
>>
>> My personal opinion is this kind of overloading is actually more
>> confusing than simply adding a new name, such as "git revert-file".
>
> I'd agree, except I think it actually worked pretty well in "git
> checkout".
>
> The alternative was to add yet another command for that, or to teach
> people about the internal commands we did have. Adding the capability for
> checkout to check out individual files - in addition to commits and
> branches - I think worked pretty well.

Why? What makes 'git checkout <commit>' and 'git checkout <commit> --
<path>' similar at all? I would expect 'git checkout <commit>' to be
the same as 'git checkout <commit> -- .'

In my mind these are 2 completely different commands.

-- 
Felipe Contreras

Re: EasyGit Integration

[Linus Torvalds]

On Thu, 11 Jun 2009, Felipe Contreras wrote:

> On Wed, Jun 10, 2009 at 7:03 AM, Linus
> Torvalds<torvalds@linux-foundation.org> wrote:
> >
> >
> > On Tue, 9 Jun 2009, Theodore Tso wrote:
> >>
> >> My personal opinion is this kind of overloading is actually more
> >> confusing than simply adding a new name, such as "git revert-file".
> >
> > I'd agree, except I think it actually worked pretty well in "git
> > checkout".
> >
> > The alternative was to add yet another command for that, or to teach
> > people about the internal commands we did have. Adding the capability for
> > checkout to check out individual files - in addition to commits and
> > branches - I think worked pretty well.
> 
> Why? What makes 'git checkout <commit>' and 'git checkout <commit> --
> <path>' similar at all? I would expect 'git checkout <commit>' to be
> the same as 'git checkout <commit> -- .'

You don't understand.

"git checkout" would be similar to "git revert", if we did that change. 

IOW, both would be "if you give it a commit, it acts at a commit level", 
and "if you give it pathnames, it acts on a pathname level".

That is totally obvious, and not in the least confusing. They are two 
different things, but at the same time, there is no question about which 
is which. 

> In my mind these are 2 completely different commands.

They are two different things, but they both make sense within the 
_context_.

Only earthworms and FOX news have no concept of "in context". So it does 
make sense to say "git checkout filename" (and expect it to check out that 
_filename_ - surprise surprise), and also say "git checkout branch" (and 
expect it to check out that branch - again, big surprise).

Humans are generally _very_ good at seeing the same word in two different 
contexts, and not being confused at all. There is no confusion when I talk 
about SCM's in the context of git, even though "SCM" could also mean a 
Sceme interpreter, or "Saskatchewan College of Midwives".

In fact, it is often *much* better to accept context-awareness, than to 
try too hard to be "uniquely identifying" even without context. 

Of course, you do want things to also be unambiguous. But that's why we 
have things like that "--" thing, when we want to specify pathspecs 
explicitly and don't want to accept any kind of ambiguity. Most humans 
tend to leave them out, and that "--" thing shows up mostly in git 
scripts.

			Linus

Re: EasyGit Integration

[Scott Chacon]

Hey,

On Wed, Jun 10, 2009 at 4:04 PM, Linus
Torvalds<torvalds@linux-foundation.org> wrote:
>
> IOW, both would be "if you give it a commit, it acts at a commit level",
> and "if you give it pathnames, it acts on a pathname level".
>
> That is totally obvious, and not in the least confusing. They are two
> different things, but at the same time, there is no question about which
> is which.
>
>> In my mind these are 2 completely different commands.
>
> They are two different things, but they both make sense within the
> _context_.
>
> Only earthworms and FOX news have no concept of "in context". So it does
> make sense to say "git checkout filename" (and expect it to check out that
> _filename_ - surprise surprise), and also say "git checkout branch" (and
> expect it to check out that branch - again, big surprise).

The problem here is that you're using 'check out' in your descriptions
of the expectations to mean two different things.  One means 'switch
branches' and the other means 'extract content'.  If you provide both
a branch and a filename, what happens? It still means 'extract
content'.  Not everyone assumes that 'checkout' can or should mean
both of these things depending on context.  I mean honestly, the
'context' of 'git checkout branch' and 'git checkout branch file'
doesn't really look that much different, but the command completely
switches semantics from 'switch active branch' to 'extract content'.
It's not that the command assumes some subtle defaults depending on
what arguments you give it - it's that it completely changes the
nature of what it does depending on the arguments.  It only makes
sense to us because we specifically learned that it did this, not
because it makes sense intuitively.  Hell, _neither_ of these meanings
are what SVN-inbound users are used to, which they map to 'extract
content _from a remote server_'.

>
> Humans are generally _very_ good at seeing the same word in two different
> contexts, and not being confused at all. There is no confusion when I talk
> about SCM's in the context of git, even though "SCM" could also mean a
> Sceme interpreter, or "Saskatchewan College of Midwives".
>
> In fact, it is often *much* better to accept context-awareness, than to
> try too hard to be "uniquely identifying" even without context.

This may be generally true for conversational language, but that
doesn't really cleanly apply here.  If your vocabulary is only like 15
words (common porcelain commands), why would one of them be ambiguous
outside of context?  Even given proper context, we're still being
arbitrary about how that command is interpreted - what if they wanted
to 'extract content' of all the files from another branch?  Having
learned that 'git checkout <file>' extracts content of that file and
'git checkout <branch> <file>' extracts the contents of that file from
that branch, why wouldn't one assume that 'git checkout <branch>'
extracts the content of all the files in that branch?  Wouldn't that
make more sense than arbitrarily doing something completely unrelated
('switching active branch')?

I'm not just arguing for arguments sake - I'm relaying from
individuals I'm trying to teach this to that they find it confusing.
This is not a theoretical argument, it is real world user feedback. I
probably struggled with things like this a bit at first and then
learned the idiosyncrasies of the tool and just accepted it like most
of the rest of us have - but many people honestly get confused and
frustrated by it. I see many of us helping people on IRC and whatnot
with this type of thing all the time.

I understand that clarity and ease of use is not really of primary
importance to this project.  However, is it not slightly ironic that
the Git project is so obsessed with squeezing 5% or 10% of raw speed
out of each command, yet feels that the onus should be on each user to
study for hours to memorize a bunch of arbitrary idiosyncrasies of the
tool?  Can we not obsess a little about flattening the learning curve
10% as well (possibly at the slight expense of command normalization
or verb bloat)?

Scott

Re: EasyGit Integration

[Jakub Narebski]

Scott Chacon <schacon@gmail.com> writes:
> On Wed, Jun 10, 2009 at 4:04 PM, Linus
> Torvalds<torvalds@linux-foundation.org> wrote:
> >
> > IOW, both would be "if you give it a commit, it acts at a commit level",
> > and "if you give it pathnames, it acts on a pathname level".
> >
> > That is totally obvious, and not in the least confusing. They are two
> > different things, but at the same time, there is no question about which
> > is which.
> >
> >> In my mind these are 2 completely different commands.
> >
> > They are two different things, but they both make sense within the
> > _context_.
> >
> > Only earthworms and FOX news have no concept of "in context". So it does
> > make sense to say "git checkout filename" (and expect it to check out that
> > _filename_ - surprise surprise), and also say "git checkout branch" (and
> > expect it to check out that branch - again, big surprise).
> 
> The problem here is that you're using 'check out' in your descriptions
> of the expectations to mean two different things.  One means 'switch
> branches' and the other means 'extract content'.

In both cases it means getting something out of repository (checking
out) and into working area.

> If you provide both
> a branch and a filename, what happens? It still means 'extract
> content'.  

If there is a filename,  then it is checking out a file or files.
If there is no filename, then it is checking out a commit.

Checking out commit means switching branch if it is branch name,
detaching HEAD if it is not branch name.

When you are checking out a file or set of files, you cannot change
branch; commit is state of a whole project, not of individual files.

> Not everyone assumes that 'checkout' can or should mean
> both of these things depending on context.  I mean honestly, the
> 'context' of 'git checkout branch' and 'git checkout branch file'
> doesn't really look that much different, but the command completely
> switches semantics from 'switch active branch' to 'extract content'.

Note that "git checkout <commit-ish>" was first (well, it was only 
"git checkout <branch>" then.

> It's not that the command assumes some subtle defaults depending on
> what arguments you give it - it's that it completely changes the
> nature of what it does depending on the arguments.  It only makes
> sense to us because we specifically learned that it did this, not
> because it makes sense intuitively.  Hell, _neither_ of these meanings
> are what SVN-inbound users are used to, which they map to 'extract
> content _from a remote server_'.

So perhaps _understanding_ those commands require understanding git
model.  I don't see how this is a bad thing.  You would have to learn
it anyway... ;-)

[...]
> I understand that clarity and ease of use is not really of primary
> importance to this project.  However, is it not slightly ironic that
> the Git project is so obsessed with squeezing 5% or 10% of raw speed
> out of each command, yet feels that the onus should be on each user to
> study for hours to memorize a bunch of arbitrary idiosyncrasies of the
> tool?  Can we not obsess a little about flattening the learning curve
> 10% as well (possibly at the slight expense of command normalization
> or verb bloat)?

The problem is bakcward compatibility and the fact that git was not as
much as designed, as it has grown.  Which is very good solution for
getting good feature set, but not so much for an UI...

-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: EasyGit Integration

[Felipe Contreras]

On Thu, Jun 11, 2009 at 3:15 AM, Jakub Narebski<jnareb@gmail.com> wrote:
> Scott Chacon <schacon@gmail.com> writes:
>> On Wed, Jun 10, 2009 at 4:04 PM, Linus
>> Torvalds<torvalds@linux-foundation.org> wrote:
>> >
>> > IOW, both would be "if you give it a commit, it acts at a commit level",
>> > and "if you give it pathnames, it acts on a pathname level".
>> >
>> > That is totally obvious, and not in the least confusing. They are two
>> > different things, but at the same time, there is no question about which
>> > is which.
>> >
>> >> In my mind these are 2 completely different commands.
>> >
>> > They are two different things, but they both make sense within the
>> > _context_.
>> >
>> > Only earthworms and FOX news have no concept of "in context". So it does
>> > make sense to say "git checkout filename" (and expect it to check out that
>> > _filename_ - surprise surprise), and also say "git checkout branch" (and
>> > expect it to check out that branch - again, big surprise).
>>
>> The problem here is that you're using 'check out' in your descriptions
>> of the expectations to mean two different things.  One means 'switch
>> branches' and the other means 'extract content'.
>
> In both cases it means getting something out of repository (checking
> out) and into working area.

'git reset' also gets something out of the repository and into the
working area, that's not reason enough to put them under the same
'checkout' command, is it?

> [...]
>> I understand that clarity and ease of use is not really of primary
>> importance to this project.  However, is it not slightly ironic that
>> the Git project is so obsessed with squeezing 5% or 10% of raw speed
>> out of each command, yet feels that the onus should be on each user to
>> study for hours to memorize a bunch of arbitrary idiosyncrasies of the
>> tool?  Can we not obsess a little about flattening the learning curve
>> 10% as well (possibly at the slight expense of command normalization
>> or verb bloat)?
>
> The problem is bakcward compatibility and the fact that git was not as
> much as designed, as it has grown.  Which is very good solution for
> getting good feature set, but not so much for an UI...

Backwards compatibility must be broken at some point or another,
otherwise people will start to create their own aliases, alternative
UI's and even forks. Sure, it must be done carefully and planned in
advance, that's why it's a good idea to keep a list of things to
change in the next interface break.

-- 
Felipe Contreras

Re: EasyGit Integration

[Jakub Narebski]

On Thu, 11 June 2009, Felipe Contreras wrote:
> On Thu, Jun 11, 2009 at 3:15 AM, Jakub Narebski<jnareb@gmail.com> wrote:
>> Scott Chacon <schacon@gmail.com> writes:
>>> On Wed, Jun 10, 2009 at 4:04 PM, Linus
>>> Torvalds<torvalds@linux-foundation.org> wrote:
>>>>
>>>> IOW, both would be "if you give it a commit, it acts at a commit level",
>>>> and "if you give it pathnames, it acts on a pathname level".
>>>>
>>>> That is totally obvious, and not in the least confusing. They are two
>>>> different things, but at the same time, there is no question about which
>>>> is which.
>>>>
>>>>> In my mind these are 2 completely different commands.
>>>>
>>>> They are two different things, but they both make sense within the
>>>> _context_.
>>>>
>>>> Only earthworms and FOX news have no concept of "in context". So it does
>>>> make sense to say "git checkout filename" (and expect it to check out that
>>>> _filename_ - surprise surprise), and also say "git checkout branch" (and
>>>> expect it to check out that branch - again, big surprise).
>>>
>>> The problem here is that you're using 'check out' in your descriptions
>>> of the expectations to mean two different things.  One means 'switch
>>> branches' and the other means 'extract content'.
>>
>> In both cases it means getting something out of repository (checking
>> out) and into working area.
> 
> 'git reset' also gets something out of the repository and into the
> working area, that's not reason enough to put them under the same
> 'checkout' command, is it?

Nope. 'git reset' resets something to the state in repository (to given
commit).  The fact that some combination of options for 'git reset' gives
the same result as some specific combination of options of 'git checkout'
means only that one can arrive at some destination in two different ways.

-- 
Jakub Narebski
Poland

Re: EasyGit Integration

[Felipe Contreras]

On Thu, Jun 11, 2009 at 3:42 AM, Jakub Narebski<jnareb@gmail.com> wrote:
> On Thu, 11 June 2009, Felipe Contreras wrote:
>> On Thu, Jun 11, 2009 at 3:15 AM, Jakub Narebski<jnareb@gmail.com> wrote:
>>> Scott Chacon <schacon@gmail.com> writes:
>>>> On Wed, Jun 10, 2009 at 4:04 PM, Linus
>>>> Torvalds<torvalds@linux-foundation.org> wrote:
>>>>>
>>>>> IOW, both would be "if you give it a commit, it acts at a commit level",
>>>>> and "if you give it pathnames, it acts on a pathname level".
>>>>>
>>>>> That is totally obvious, and not in the least confusing. They are two
>>>>> different things, but at the same time, there is no question about which
>>>>> is which.
>>>>>
>>>>>> In my mind these are 2 completely different commands.
>>>>>
>>>>> They are two different things, but they both make sense within the
>>>>> _context_.
>>>>>
>>>>> Only earthworms and FOX news have no concept of "in context". So it does
>>>>> make sense to say "git checkout filename" (and expect it to check out that
>>>>> _filename_ - surprise surprise), and also say "git checkout branch" (and
>>>>> expect it to check out that branch - again, big surprise).
>>>>
>>>> The problem here is that you're using 'check out' in your descriptions
>>>> of the expectations to mean two different things.  One means 'switch
>>>> branches' and the other means 'extract content'.
>>>
>>> In both cases it means getting something out of repository (checking
>>> out) and into working area.
>>
>> 'git reset' also gets something out of the repository and into the
>> working area, that's not reason enough to put them under the same
>> 'checkout' command, is it?
>
> Nope. 'git reset' resets something to the state in repository (to given
> commit).  The fact that some combination of options for 'git reset' gives
> the same result as some specific combination of options of 'git checkout'
> means only that one can arrive at some destination in two different ways.

You can describe what 'git reset' does in many ways, but in the
process it's still getting something out of the repository and into
the working directory, does it not? 'git checkout <commitish>' and
'git checkout <commitish> -- <path>' also do that.

Is that relevant? No. What is relevant is the final action the user is
expecting to achieve.

Therefore, the fact that 'git checkout <commitish>' modifies the
working directory is irrelevant, it's still doing an extra step;
update HEAD, and that final action is what is important for this
particular command; it switches to another commitish.

-- 
Felipe Contreras

Re: EasyGit Integration

[Jakub Narebski]

On Fri, 12 Jun 2009, Felipe Contreras wrote:
> On Thu, Jun 11, 2009 at 3:42 AM, Jakub Narebski<jnareb@gmail.com> wrote:
>> On Thu, 11 June 2009, Felipe Contreras wrote:

>>> 'git reset' also gets something out of the repository and into the
>>> working area, that's not reason enough to put them under the same
>>> 'checkout' command, is it?
>>
>> Nope. 'git reset' resets something to the state in repository (to given
>> commit).  The fact that some combination of options for 'git reset' gives
>> the same result as some specific combination of options of 'git checkout'
>> means only that one can arrive at some destination in two different ways.
> 
> You can describe what 'git reset' does in many ways, but in the
> process it's still getting something out of the repository and into
> the working directory, does it not? 'git checkout <commitish>' and
> 'git checkout <commitish> -- <path>' also do that.

Nope. 'git reset' always reset some part of state to a given commit,
HEAD by default.  It can reset current branch with --soft, branch plus
index with --mixed (default), and branch plus index plus working 
directory with --hard.  Source is always commit.

'git checkout' however checks out something into working directory.
It can be branch, in which turns it sets HEAD to point to it, and
index too.  It can be file, in which it gets version of file from
index or (if specified) from given commit.  Destination is always
working area (and sometimes something else beside it).

> 
> Is that relevant? No. What is relevant is the final action the user is
> expecting to achieve.
> 
> Therefore, the fact that 'git checkout <commitish>' modifies the
> working directory is irrelevant, it's still doing an extra step;
> update HEAD, and that final action is what is important for this
> particular command; it switches to another commitish.

It is not uncommon for a word to have different meaning depending on
context, or on some auxiliary word used in addition...
-- 
Jakub Narebski
Poland

Re: EasyGit Integration

[Felipe Contreras]

On Sat, Jun 13, 2009 at 12:21 AM, Jakub Narebski<jnareb@gmail.com> wrote:
> On Fri, 12 Jun 2009, Felipe Contreras wrote:
>> On Thu, Jun 11, 2009 at 3:42 AM, Jakub Narebski<jnareb@gmail.com> wrote:
>>> On Thu, 11 June 2009, Felipe Contreras wrote:
>
>>>> 'git reset' also gets something out of the repository and into the
>>>> working area, that's not reason enough to put them under the same
>>>> 'checkout' command, is it?
>>>
>>> Nope. 'git reset' resets something to the state in repository (to given
>>> commit).  The fact that some combination of options for 'git reset' gives
>>> the same result as some specific combination of options of 'git checkout'
>>> means only that one can arrive at some destination in two different ways.
>>
>> You can describe what 'git reset' does in many ways, but in the
>> process it's still getting something out of the repository and into
>> the working directory, does it not? 'git checkout <commitish>' and
>> 'git checkout <commitish> -- <path>' also do that.
>
> Nope. 'git reset' always reset some part of state to a given commit,
> HEAD by default.  It can reset current branch with --soft, branch plus
> index with --mixed (default), and branch plus index plus working
> directory with --hard.  Source is always commit.

You said it: 'git reset --hard' gets something out of the repository
and into the working directory.

Try this:
git checkout <random sha-1 with no ref>

Then what is the difference between:
git checkout HEAD^
git reset --hard HEAD^

In this case they do exactly the same thing, don't they?

> 'git checkout' however checks out something into working directory.
> It can be branch, in which turns it sets HEAD to point to it, and
> index too.  It can be file, in which it gets version of file from
> index or (if specified) from given commit.  Destination is always
> working area (and sometimes something else beside it).
>
>>
>> Is that relevant? No. What is relevant is the final action the user is
>> expecting to achieve.
>>
>> Therefore, the fact that 'git checkout <commitish>' modifies the
>> working directory is irrelevant, it's still doing an extra step;
>> update HEAD, and that final action is what is important for this
>> particular command; it switches to another commitish.
>
> It is not uncommon for a word to have different meaning depending on
> context, or on some auxiliary word used in addition...

We are talking about a command here, not a command that has two slight
variations of the same main action, a command that is doing *two*
completely unrelated actions depending on the context.

Think about these 3 actions:
a) get a path out of a commit in the repository and into the working directory
b) switch to another commit, reseting the working directory
c) reset current branch to certain commit, and checkout into the
working directory

The 3 actions require putting something into the working directory;
what makes a) and b) so similar they belong to the same command?

-- 
Felipe Contreras

Re: EasyGit Integration

[Jakub Narebski]

On Fri, 12 Jun 2009, Felipe Contreras wrote:
> On Sat, Jun 13, 2009 at 12:21 AM, Jakub Narebski<jnareb@gmail.com> wrote:

>> Nope. 'git reset' always reset some part of state to a given commit,
>> HEAD by default.  It can reset current branch with --soft, branch plus
>> index with --mixed (default), and branch plus index plus working
>> directory with --hard.  Source is always commit.
> 
> You said it: 'git reset --hard' gets something out of the repository
> and into the working directory.
> 
> Try this:
> git checkout <random sha-1 with no ref>
> 
> Then what is the difference between:
> git checkout HEAD^
> git reset --hard HEAD^
> 
> In this case they do exactly the same thing, don't they?

No, they don't.  "git checkout HEAD^" modifies HEAD detaching it.
"git reset --hard HEAD^" modifies branch that HEAD points to (well,
unless HEAD is detached).

-- 
Jakub Narebski
Poland

Re: EasyGit Integration

[Felipe Contreras]

On Sat, Jun 13, 2009 at 1:05 AM, Jakub Narebski<jnareb@gmail.com> wrote:
> On Fri, 12 Jun 2009, Felipe Contreras wrote:
>> On Sat, Jun 13, 2009 at 12:21 AM, Jakub Narebski<jnareb@gmail.com> wrote:
>
>>> Nope. 'git reset' always reset some part of state to a given commit,
>>> HEAD by default.  It can reset current branch with --soft, branch plus
>>> index with --mixed (default), and branch plus index plus working
>>> directory with --hard.  Source is always commit.
>>
>> You said it: 'git reset --hard' gets something out of the repository
>> and into the working directory.
>>
>> Try this:
>> git checkout <random sha-1 with no ref>
>>
>> Then what is the difference between:
>> git checkout HEAD^
>> git reset --hard HEAD^
>>
>> In this case they do exactly the same thing, don't they?
>
> No, they don't.  "git checkout HEAD^" modifies HEAD detaching it.
> "git reset --hard HEAD^" modifies branch that HEAD points to (well,
> unless HEAD is detached).

Read again:
>> git checkout <random sha-1 with no ref>

The HEAD is detached, so they do exactly the same in this case.

-- 
Felipe Contreras

Re: EasyGit Integration

[Björn Steinbrink]

On 2009.06.13 01:30:38 +0300, Felipe Contreras wrote:
> On Sat, Jun 13, 2009 at 1:05 AM, Jakub Narebski<jnareb@gmail.com> wrote:
> > On Fri, 12 Jun 2009, Felipe Contreras wrote:
> >> On Sat, Jun 13, 2009 at 12:21 AM, Jakub Narebski<jnareb@gmail.com> wrote:
> >
> >>> Nope. 'git reset' always reset some part of state to a given commit,
> >>> HEAD by default.  It can reset current branch with --soft, branch plus
> >>> index with --mixed (default), and branch plus index plus working
> >>> directory with --hard.  Source is always commit.
> >>
> >> You said it: 'git reset --hard' gets something out of the repository
> >> and into the working directory.
> >>
> >> Try this:
> >> git checkout <random sha-1 with no ref>
> >>
> >> Then what is the difference between:
> >> git checkout HEAD^
> >> git reset --hard HEAD^
> >>
> >> In this case they do exactly the same thing, don't they?
> >
> > No, they don't.  "git checkout HEAD^" modifies HEAD detaching it.
> > "git reset --hard HEAD^" modifies branch that HEAD points to (well,
> > unless HEAD is detached).
> 
> Read again:
> >> git checkout <random sha-1 with no ref>
> 
> The HEAD is detached, so they do exactly the same in this case.

Not if there are uncommitted changes to tracked files.

Björn

Re: EasyGit Integration

[Felipe Contreras]

On Thu, Jun 11, 2009 at 2:04 AM, Linus
Torvalds<torvalds@linux-foundation.org> wrote:
>
>
> On Thu, 11 Jun 2009, Felipe Contreras wrote:
>
>> On Wed, Jun 10, 2009 at 7:03 AM, Linus
>> Torvalds<torvalds@linux-foundation.org> wrote:
>> >
>> >
>> > On Tue, 9 Jun 2009, Theodore Tso wrote:
>> >>
>> >> My personal opinion is this kind of overloading is actually more
>> >> confusing than simply adding a new name, such as "git revert-file".
>> >
>> > I'd agree, except I think it actually worked pretty well in "git
>> > checkout".
>> >
>> > The alternative was to add yet another command for that, or to teach
>> > people about the internal commands we did have. Adding the capability for
>> > checkout to check out individual files - in addition to commits and
>> > branches - I think worked pretty well.
>>
>> Why? What makes 'git checkout <commit>' and 'git checkout <commit> --
>> <path>' similar at all? I would expect 'git checkout <commit>' to be
>> the same as 'git checkout <commit> -- .'
>
> You don't understand.
>
> "git checkout" would be similar to "git revert", if we did that change.
>
> IOW, both would be "if you give it a commit, it acts at a commit level",
> and "if you give it pathnames, it acts on a pathname level".
>
> That is totally obvious, and not in the least confusing. They are two
> different things, but at the same time, there is no question about which
> is which.

I'm opposed to 'git revert -- <path>' for many reasons, one of which
is; you might want to grab some files that are in a future commit.
Reverting to the future is weird, unless you did a previous revert
backwards.

I do understand the two different 'git checkout' modes, that's not the
point, my point is the question you didn't answer; what does 'git
checkout <commit>' and 'git checkout -- <path>' have in common?

To me it seems the only thing they have in common is the name.

>> In my mind these are 2 completely different commands.
>
> They are two different things, but they both make sense within the
> _context_.
>
> Only earthworms and FOX news have no concept of "in context". So it does
> make sense to say "git checkout filename" (and expect it to check out that
> _filename_ - surprise surprise), and also say "git checkout branch" (and
> expect it to check out that branch - again, big surprise).
>
> Humans are generally _very_ good at seeing the same word in two different
> contexts, and not being confused at all. There is no confusion when I talk
> about SCM's in the context of git, even though "SCM" could also mean a
> Sceme interpreter, or "Saskatchewan College of Midwives".

Suppose you have a 'debian' branch, and a 'debian' directory, what
does this command do?
git checkout debian

Sure, I'm not an earthworm, so I can guess that command means checkout
the debian branch because it's a much more common action. But git
doesn't know that, you need to do:
git checkout debian --

If I know I want to checkout a branch I would like to do:
git <command to checkout a branch> debian

> In fact, it is often *much* better to accept context-awareness, than to
> try too hard to be "uniquely identifying" even without context.
>
> Of course, you do want things to also be unambiguous. But that's why we
> have things like that "--" thing, when we want to specify pathspecs
> explicitly and don't want to accept any kind of ambiguity. Most humans
> tend to leave them out, and that "--" thing shows up mostly in git
> scripts.

Yeah, unless git finds it ambiguous and the user is forced to learn a
new idiom in order to get rid of the ambiguity.

-- 
Felipe Contreras

Re: EasyGit Integration

[Elijah Newren]

On Tue, Jun 9, 2009 at 9:32 PM, Theodore Tso<tytso@mit.edu> wrote:
> My personal opinion is this kind of overloading is actually more
> confusing than simply adding a new name, such as "git revert-file".
> Of course, you can do that already using a git alias....  So IMHO the
> best way of handling this issue is to have git tutorials use this as a
> teachable moment, so people can create their own git alias for "git
> checkout HEAD --".

So I have a few problems with such an alias:
* It fails to work during an initial commit ("git revert-files
new-file" -> "fatal: invalid reference: HEAD")
* When not working on the initial commit, it will silently do nothing
when given a newly added file rather than undoing the add
* As a side effect of the above, trying to undo all changes via "git
revert-files ." does not actually work; any newly added files will
still remain staged.
* It makes no sense during an incomplete merge (why is HEAD more
special than other refs in $git_dir/MERGE_HEAD?  Shouldn't the user
need to specify which ref to revert relative to in such a case?)
* It can't be used to revert a file back to a revision prior to HEAD
(and 'git checkout OLDER_COMMIT -- FILE' in such a case isn't always
the right match either as it can leave the file in the working copy
when it should be removed).
* It provides no option to make the changes to just the index or just
the working copy; it always affects both (which is the right default,
but sometimes I like making changes to just one of those two places).

"git checkout <commit> -- <paths>..."  really is a different command
than the "revert" of svn, bzr, darcs, or mercurial.  There's clearly a
lot of overlap, but they're not the same.  I fear that claiming they
are equivalent will at some point just cause extra confusion for new
git users.


Elijah

Re: EasyGit Integration

[Matthieu Moy]

Linus Torvalds <torvalds@linux-foundation.org> writes:

> I would not object to
>
>  - old behavior: revert the commit by creating an "anti-commit":
>
> 	git revert <cmit-name>
>
>  - new extension: revert the state of the working tree to the HEAD:
>
> 	git revert [--] pathspec
>
> which would kind of match the semantics of "git checkout" does.

That's subjective, but I would find this more misleading than the
current behavior. To me, that would let beginners think that both
commands do similar things, and then "why the hell does git revert
HEAD^^ create a commit while git revert -- foo.c doesn't???"-kind of
questions.

my 2 cents,

-- 
Matthieu

Re: EasyGit Integration

[Sam Vilain]

Linus Torvalds wrote:
> On Tue, 9 Jun 2009, Scott Chacon wrote:
>   
>> * breaks the various things that 'checkout' does into separate
>> commands - moves 'revert' to doing what 'checkout -- path' does
>>     
>
> No.
>
> NAK on this one. 
>
> The fact that some idiotic SVN usage exists is not an excuse to break 
> long-standing git users. "revert" comes from bk, and quite frankly, I 
> object _very_ strongly to taking naming from something that is very 
> obviously the inferior system (SVN) over something very obviously superior 
> (BK and git).
>   

We talked about this much at GitTogether '08. It's true that for
'reverting' a change in the past, that is the right thing to do. However
I don't think there is a first principles case that this is always what
people mean by 'revert'. And it is not just SVN - Mercurial, Monotone,
Bazaar, Darcs all use 'revert' in this way. By comparison with those
systems, the number of users coming from BK is quite low.

We talked about making a 'git revert-file' and 'git revert-commit', with
'git revert' printing a message encouraging the user to specify which
one they wanted (or potentially pointing them to the correct
incantations of 'git checkout' or 'git cherry-pick').

I think as long as there is a deprecation cycle, and that users can
select the old behaviour (either via an alias or a config option), then
we shouldn't upset many long-time users of revert. Do you agree?

Sam.

Re: EasyGit Integration

[Linus Torvalds]

On Wed, 10 Jun 2009, Sam Vilain wrote:
> 
> We talked about making a 'git revert-file' and 'git revert-commit', with
> 'git revert' printing a message encouraging the user to specify which
> one they wanted (or potentially pointing them to the correct
> incantations of 'git checkout' or 'git cherry-pick').
> 
> I think as long as there is a deprecation cycle, and that users can
> select the old behaviour (either via an alias or a config option), then
> we shouldn't upset many long-time users of revert. Do you agree?

No. I disagree. What the hell is the point in making an _inferior_ name 
for what we already have?

I violently disagree with making git worse just because somebody cannot 
bother to learn it. And it really is about "bother" - it's clearly not 
about anything else.

I also don't see why you'd also then advocate a clearly inferior model 
with two different commands, when you _could_ just do the "commitname" vs 
"pathspec" model. 

		Linus

Re: EasyGit Integration

[Junio C Hamano]

Sam Vilain <sam@vilain.net> writes:

> We talked about this much at GitTogether '08. It's true that for
> 'reverting' a change in the past, that is the right thing to do. However
> I don't think there is a first principles case that this is always what
> people mean by 'revert'....

Sorry; what you think people mean by 'revert' does not matter at this
point, unless you are building a brand-new system from scratch.

> I think as long as there is a deprecation cycle, and that users can
> select the old behaviour (either via an alias or a config option), then
> we shouldn't upset many long-time users of revert. Do you agree?

I actually don't.

I do not think introducing "git revert-file" (or "git revert -- path") is
a problem at all.  But "git revert $commit" has been and is an integral
part of the established git workflow, and I do not see a point in changing
it to mean something else, with any deprecation period.

By the way, I have a bigger issue.

Some changes in "eg" may port well as a new command to git-core, and some
change (like this "revert" thing that has different semantics and breaks
established workflow) will never be in git-core.  People may think that it
would not cause many problems if we picked only the non-conflicting bits,
but I actually have some reservations about that.

It will bloat the total number of subcommands you can give git, with the
end result being

 (1) old timers won't use "revert-commit" and "revert-file" at all but use
     "revert" and "checkout -- path"; while

 (2) new people will behave the other way; and

 (3) the documentation will list all of commands from these two disjoint
    sets under "git".

When a "eg" minded person teaches git, the students may have to be told to
ignore "revert" and "checkout -- path", because there are other ways to do
the same thing in the lingo they are being taught, which is a subset of
git commands.  The manual pages will be littered with descriptions like
"this command, when used this way, is synonymous to using that other
command with this option", leaving the reader wondering why there are so
many ways to do the same thing.

If "eg" (I do not have _anything_ against it; the discussion applies to
other Porcelains as well) were kept independent _and_ offered complete set
of features that users need without resorting to git-core, on the other
hand, the students do not have to know about "revert", and the manuals
they need to consult will not have to talk about "if you are using
git-core, this is done differently in this way".  The learning curve will
get a lot smoother for new people.

If new and useful features (e.g. "creating a remote repository over SSH in
one shot") are supported by another Porcelain (e.g.  "eg") they may be
worth porting over to git-core, in order to make git-core more usable.
There is a precedent for that kind of side port (e.g. "filter-branch" that
came from Cogito).

But aliases for doing essentially the same thing in slightly different
syntax?  I'd rather not to see them called "git foo".  In the end, I think
it will harm the users, both new and old.

If you go back to the list archive, you will find me suggesting a new set
of commands with "gh" prefix, back in 1.3.X days, I think.

I was not joking.  The reasoning was exactly the same, and it remains so.

Re: EasyGit Integration

[Sam Vilain]

Junio C Hamano wrote:
>> I think as long as there is a deprecation cycle, and that users can
>> select the old behaviour (either via an alias or a config option), then
>> we shouldn't upset many long-time users of revert. Do you agree?
>>     
>
> I actually don't.
>
> I do not think introducing "git revert-file" (or "git revert -- path") is
> a problem at all.  But "git revert $commit" has been and is an integral
> part of the established git workflow, and I do not see a point in changing
> it to mean something else, with any deprecation period.
>   

Ok. Off-hand I can't remember why we excluded "git revert -- path" as
workable. Whatever that reason was led to the group of core developers
coming up with these "clearly" "_inferior_" names.

That could solve the problem, switching behaviour on the type of
argument passed rather than including it in the command name. I think
that was my preferred option at the time, too. Perhaps some other
attendees can recall more clearly...

> Some changes in "eg" may port well as a new command to git-core, and some
> change (like this "revert" thing that has different semantics and breaks
> established workflow) will never be in git-core.  People may think that it
> would not cause many problems if we picked only the non-conflicting bits,
> but I actually have some reservations about that.
>
> It will bloat the total number of subcommands you can give git, with the
> end result being
>
>  (1) old timers won't use "revert-commit" and "revert-file" at all but use
>      "revert" and "checkout -- path"; while
>
>  (2) new people will behave the other way; and
>
>  (3) the documentation will list all of commands from these two disjoint
>     sets under "git".
>
> When a "eg" minded person teaches git, the students may have to be told to
> ignore "revert" and "checkout -- path", because there are other ways to do
> the same thing in the lingo they are being taught, which is a subset of
> git commands.  The manual pages will be littered with descriptions like
> "this command, when used this way, is synonymous to using that other
> command with this option", leaving the reader wondering why there are so
> many ways to do the same thing.
>   

Yes, I agree that if the old behaviour is not being deprecated it
probably shouldn't be replicated as well.

In fact that may have been the argument for excluding 'git revert
filename' - because you can already do that with 'git checkout HEAD --
filename'; but perhaps in this case it is acceptable, because the
'checkout' command can also check out from other revisions, but revert
can't.

Sam.

Re: EasyGit Integration

[Jakub Narebski]

Sam Vilain <sam@vilain.net> writes:
> Junio C Hamano wrote:
>>
>>> I think as long as there is a deprecation cycle, and that users can
>>> select the old behaviour (either via an alias or a config option), then
>>> we shouldn't upset many long-time users of revert. Do you agree?
>>>     
>>
>> I actually don't.
>>
>> I do not think introducing "git revert-file" (or "git revert -- path") is
>> a problem at all.  But "git revert $commit" has been and is an integral
>> part of the established git workflow, and I do not see a point in changing
>> it to mean something else, with any deprecation period.
>>   
> 
> Ok. Off-hand I can't remember why we excluded "git revert -- path" as
> workable. Whatever that reason was led to the group of core developers
> coming up with these "clearly" "_inferior_" names.

"git revert -- path" is perhaps not unambiguous (but for the fact
whether it reverts from index, or from HEAD), but "git revert <rev> -- path"
can be understood as "git cherry-pick -R <rev> -- path" i.e. reverting
changes to given file or files in a commit.

And we have "git reset -- file", don't we.
-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: EasyGit Integration

[Nicolas Pitre]

On Tue, 9 Jun 2009, Junio C Hamano wrote:

> Some changes in "eg" may port well as a new command to git-core, and some
> change (like this "revert" thing that has different semantics and breaks
> established workflow) will never be in git-core.  People may think that it
> would not cause many problems if we picked only the non-conflicting bits,
> but I actually have some reservations about that.
> 
> It will bloat the total number of subcommands you can give git, with the
> end result being
> 
>  (1) old timers won't use "revert-commit" and "revert-file" at all but use
>      "revert" and "checkout -- path"; while
> 
>  (2) new people will behave the other way; and
> 
>  (3) the documentation will list all of commands from these two disjoint
>     sets under "git".

Nah.  This doesn't have to be so extreme.  Your example above is 
relevant, and I agree with you that this is unnecessary bloat.

However there are many other examples, such as "git branch -s" being 
equivalent to "git checkout -b" which I think are rather nice to have.

The 'git resolved' command for staging resolved conflicts is also nice.

Also does the streamlining of --abort/--continue for a couple commands.

This is why I said that such additions should be proposed piecemeal and 
judged separately.

> When a "eg" minded person teaches git, the students may have to be told to
> ignore "revert" and "checkout -- path", because there are other ways to do
> the same thing in the lingo they are being taught, which is a subset of
> git commands.  The manual pages will be littered with descriptions like
> "this command, when used this way, is synonymous to using that other
> command with this option", leaving the reader wondering why there are so
> many ways to do the same thing.

This is not necessarily a good strategy to always list all equivalences.  
If someone learns from the git-branch man page that -s also switches to 
the newly created branch, then that person won't gain anything nor care 
to know that 'git checkout -b' does the same.

> If "eg" (I do not have _anything_ against it; the discussion applies to
> other Porcelains as well) were kept independent _and_ offered complete set
> of features that users need without resorting to git-core, on the other
> hand, the students do not have to know about "revert", and the manuals
> they need to consult will not have to talk about "if you are using
> git-core, this is done differently in this way".  The learning curve will
> get a lot smoother for new people.

On the other hand, having multiple porcelains simply divide the user 
base which is not always a good thing.  Look at what happened to cogito 
for example: some people were using it, some people didn't and those two 
groups couldn't help each other efficiently.  Yet git used to do things 
badly that cogito did well, and the other way around too, which gave the 
impression that each system was suboptimal.  When git picked up the good 
things in cogito and cogito finally died then everybody was focusing on 
a single command-line-based porcelain for the better health of git which 
really gained momentum at that point.

In that sense, an alternative (command line) porcelain is effectively a 
fork.  Forks are good for experimental stuff and the like, but 
eventually it is always best for everyone involved if the better parts 
of the fork are merged back.  Any project with a fork that grew big and 
didn't merge back made the whole community weaker in the long run.

> If new and useful features (e.g. "creating a remote repository over SSH in
> one shot") are supported by another Porcelain (e.g.  "eg") they may be
> worth porting over to git-core, in order to make git-core more usable.
> There is a precedent for that kind of side port (e.g. "filter-branch" that
> came from Cogito).
> 
> But aliases for doing essentially the same thing in slightly different
> syntax?  I'd rather not to see them called "git foo".  In the end, I think
> it will harm the users, both new and old.

Again this should be evaluated on a case by case basis.  I think this is 
clear already that re-targeting commands like revert is _not_ a good 
idea.  But some other examples are not so controversial.

> If you go back to the list archive, you will find me suggesting a new set
> of commands with "gh" prefix, back in 1.3.X days, I think.
> 
> I was not joking.  The reasoning was exactly the same, and it remains so.

And my opinion as explained above is that it is not a good idea.  Your 
suggestion didn't take off for a good reason.


Nicolas

Re: EasyGit Integration

[Junio C Hamano]

Nicolas Pitre <nico@cam.org> writes:

> On the other hand, having multiple porcelains simply divide the user 
> base which is not always a good thing.

The addition of new synonymous commands or options has the same issue of
dividing the user base between revert-commit/revert-file folks and
revert/checkout people.  In addition, it has the subcommand bloat issue I
already mentioned.  If anything, we should be aiming for _reducing_ them
from the current set of ~150; it is silly to dismiss it, saying "one extra
added to 150 is less than 1%".

As long as the "fork" is feature complete and the user does not have to
resort to git-core, even though it may share the same issue of user base
division, at least that would _help_ the users who choose the forked one,
who does not have to know the old-timer lingo and concepts.  It would be a
much better solution than adding stupid synonyms to the existing system.

But coming up with a consistent and complete fork that does not show
git-core (not just phrases but also underlying concepts) is a lot of work.
That is the primary reason why nobody did "gh".

>> But aliases for doing essentially the same thing in slightly different
>> syntax?  I'd rather not to see them called "git foo".  In the end, I think
>> it will harm the users, both new and old.
>
> Again this should be evaluated on a case by case basis.  I think this is 
> clear already that re-targeting commands like revert is _not_ a good 
> idea.  But some other examples are not so controversial.

I do not think there is any disagreement here; each proposal must be
judged separately, and no backward compatibility is allowed, unless there
is a compelling reason, a clear migration plan, and understanding of how
expensive such a backward incompatibility is by all the parties involved.

I do not see how "git branch -s" is an improvement, unless our motto is
"we will support any and all conceivable permutations of what is done to
what".  It says "while creating a branch, switch to it".  We say "while
switching to a new commit, start a branch by given name there".

I'd throw it into "if we did not have X in the beginning, instead of
adding X, we could have added Y and it would have worked equally well"
category.

But we already have X.

A rule of thumb I use for judging such a case is that Y must be at least
10 times better than X to replace it, and that has to happen with some
deprecation period.  Supporting Y in addition to X may probably have lower
hurdle, but still Y must be much better than X for that to happen.

If "git resolved" is "git add $(git ls-files -u --name-only)" or even more
than that (say, check if the files from the work tree indeed have lost
conflict markers), I think that is a wonderful improvement.  It does not
even fall into the "Y would have worked equally well but we have X"
category, as it is something different from the existing command, and does
it better (if it works as advertised without funny corner cases, that is).

Re: EasyGit Integration

[Elijah Newren]

On Wed, Jun 10, 2009 at 2:47 PM, Junio C Hamano<gitster@pobox.com> wrote:
> As long as the "fork" is feature complete and the user does not have to
> resort to git-core, even though it may share the same issue of user base
> division, at least that would _help_ the users who choose the forked one,
> who does not have to know the old-timer lingo and concepts.  It would be a
> much better solution than adding stupid synonyms to the existing system.
>
> But coming up with a consistent and complete fork that does not show
> git-core (not just phrases but also underlying concepts) is a lot of work.
> That is the primary reason why nobody did "gh".

What would you think of adding eg to contrib?

Re: EasyGit Integration

[Scott Chacon]

Hey,

On Tue, Jun 9, 2009 at 7:18 PM, Junio C Hamano<gitster@pobox.com> wrote:
> I do not think introducing "git revert-file" (or "git revert -- path") is
> a problem at all.  But "git revert $commit" has been and is an integral
> part of the established git workflow, and I do not see a point in changing
> it to mean something else, with any deprecation period.

I would vote for simply adding 'revert-file' rather than overloading
another command with two completely different actions.

> It will bloat the total number of subcommands you can give git, with the
> end result being

It just seems that this is sort of a paving the cow paths practice - I
see a lot of people creating aliases for 'unstage' and 'revert-file'
and 'uncommit' and things that are relatively common but difficult to
remember how to do because they have very obscure syntaxes
(syntaxen?).

Worrying about subcommand bloat seems a tad silly at this point given
that there are over 150 valid verbs now, right?  If existing commands
do categorically different things depending on input values, doesn't
it make sense to simply have different verbs exist for each separate
action?  I mean, worrying about the usability issue of having too many
commands but not thinking that making users learn 'git reset HEAD
path' is an issue seems really strange to me.

> If "eg" (I do not have _anything_ against it; the discussion applies to
> other Porcelains as well) were kept independent _and_ offered complete set
> of features that users need without resorting to git-core, on the other
> hand, the students do not have to know about "revert", and the manuals
> they need to consult will not have to talk about "if you are using
> git-core, this is done differently in this way".  The learning curve will
> get a lot smoother for new people.

I think I understand the argument here, but I really, really don't
want to suggest to people to install Git and then install a separate
porcelain, and then have them spend time learning a command set that
is completely absent from other machines that have Git installed.  I
realize this is also an issue with adding new commands (in that they
would be absent from machines with older Git installed) but that issue
fades away after a few years, where the previous does not - in fact,
it becomes a far more difficult problem.

If it's not installed with 'apt-get git-core' or what have you, then I
(and I assume others) are never going to waste everyones time teaching
them a niche tool they will never find elsewhere.

> But aliases for doing essentially the same thing in slightly different
> syntax?  I'd rather not to see them called "git foo".  In the end, I think
> it will harm the users, both new and old.

It would be one thing if I were suggesting that 'git revert' be
changed to 'git regress' or something - it's not a simple naming
issue.  It's more that things like "git reset HEAD <file>..." to
unstage simply makes no sense unless you have a pretty technical
understanding of reset, the index and HEAD - none of which a beginning
user should need to learn right off the bat.  Unstaging files _is_,
however, something that a brand new user will need to do right off the
bat.  The only paths left to them, then, are either learning the
technical details of the index and 'reset' to understand why that
command makes sense, or to simply learn the command by rote - which is
nearly always what ends up happening, since it's incredibly difficult
to learn the index well.  Hell, I've been using Git pretty extensively
for years now and I still have a hard time remembering exactly what
'reset' will do in different circumstances.

Easy things that users have to do a lot should be easy, is all.
Besides just being nice for users, it would probably save a lot of
grief for you guys with people asking and complaining about these
things on this list and the IRC channel.

> If you go back to the list archive, you will find me suggesting a new set
> of commands with "gh" prefix, back in 1.3.X days, I think.
> I was not joking.  The reasoning was exactly the same, and it remains so.

Again, having to explain to people "most of the time you use gh for
all this stuff, but occasionally you use 'git'" or vice-versa is just
confusing and error prone.   Introducing some command denormalization
for the sake of getting new users on their feet with less friction
seems less painful both for the developers and experts having to help
said users and for the users themselves.

I wasn't suggesting a core rewrite, I just thought that hitting some
of this low hanging fruit - again, paving the cow paths as it were -
might be relatively painless and save everyone a lot of time.

Scott

Re: EasyGit Integration

[Felipe Contreras]

On Wed, Jun 10, 2009 at 5:18 AM, Junio C Hamano<gitster@pobox.com> wrote:
> Sam Vilain <sam@vilain.net> writes:
>
>> We talked about this much at GitTogether '08. It's true that for
>> 'reverting' a change in the past, that is the right thing to do. However
>> I don't think there is a first principles case that this is always what
>> people mean by 'revert'....
>
> Sorry; what you think people mean by 'revert' does not matter at this
> point, unless you are building a brand-new system from scratch.

Subversion is by far the most widely used VCS, it's quite likely that
new git users will come from the svn camp (I know I did), and it's
quite likely they will assume 'revert' is doing what svn does. Do you
think that doesn't matter at all?

You might think that 'git revert' is superior to 'svn revert' (and I
happen to agree with that statement), but at least you should take
into consideration the huge amount of users that would find this
behavior strange.

Personally, I would add a note to the 'git revert' documentation to be
extra-clear what 'git revert' is not.

-- 
Felipe Contreras

Re: EasyGit Integration

[Felipe Contreras]

On Tue, Jun 9, 2009 at 9: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.  I looked back to the last announcement here and the
> conversation didn't really go anywhere, sadly.  I thought it might be
> nice to adopt or at least consider a number of the design decisions
> they made in modifying the defaults and commands available.  Perhaps
> as a 1.7 goal or something?  I like it because it addresses a lot of
> the issues that I hear from beginning users:
>
> * 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
> 'reset HEAD file'.  also adds a '-s' option to 'branch' to switch to
> the branch after you create it, which many people expect rather than
> 'checkout -b'.

I like 'git unstage', but not the rest.

> * adds 'git resolved' for 'git add', which I hear all the time as
> being confusing

I would prefer 'git stage'; 'git resolved' seems to be meant for a
very particular case: resolve conflicts, it would be much better to
learn that you can do 'git stage' at any time.

<snip/>

> * 'git backout' for 'git reset HEAD^'

I don't like that. Looks like a very specialized case. It's much
better to learn this particular use of 'git reset'.

> * 'git push origin --delete <branch>' for 'git push origin :branch'

That would be really good, it took me a lot of time to find that idiom.

Cheers.

-- 
Felipe Contreras