Re: [PATCH] cmd_reset: don't trash uncommitted changes unless told to

Theodore Tso [off-list ref] writes:

I used to argue for this, but gave up, because no one seemed to agree
with me.  So now I just have the following in
/home/tytso/bin/git-revert-file and I am very happy:

#!/bin/sh
#
prefix=$(git rev-parse --show-prefix)

for i in $*
do
        git show HEAD:$prefix$i > $i
done

Isn't that this?

        #!/bin/sh
        exec git checkout HEAD -- "$@"

On Wed, Jun 25, 2008 at 10:22:08AM -0700, Junio C Hamano wrote:

Isn't that this?

        #!/bin/sh
        exec git checkout HEAD -- "$@"

Well, I think you really want this to handle filenames with spaces:

for i in $*
do
    git checkout HEAD -- "$i"
done

I still think it would be nice this as a built-in for "git
revert-file" since this is much easier to type than "git checkout HEAD
-- " (all those characters and capital letters).  But if it ends up
being a private shell script for people who do this a lot, that's also fine.

I will say that it was not at all obvious that "git checkout" can also
be used to revert files, so it wasn't one of the man pages that looked
for when trying to figure out how to implement revert files.  That's
why I ended up using:

    git show HEAD:$prefix$i > $i

      		      	     	 	    - Ted

On 6/25/08, Theodore Tso [off-list ref] wrote:

On Wed, Jun 25, 2008 at 10:22:08AM -0700, Junio C Hamano wrote:
 >         exec git checkout HEAD -- "$@"

Well, I think you really want this to handle filenames with spaces:

 for i in $*
 do
    git checkout HEAD -- "$i"
 done

"$@" notation actually handles spaces just fine.  It's magic that way.
 On the other hand, "for i in $*" does not, because all the spaces get
split as part of the unquoted $* in "for".  Beware!

 I still think it would be nice this as a built-in for "git
 revert-file" since this is much easier to type than "git checkout HEAD
 -- " (all those characters and capital letters).  But if it ends up
 being a private shell script for people who do this a lot, that's also fine.

How about making "git checkout" default to HEAD if no revision is
supplied?  There's precedent for this in, say, git-diff (and I think a
few others).

Incidentally, "checkout <filename>" was also the way to do a revert
operation in CVS.  And the way to switch branches, too, iirc.  So git
isn't being too unusual here.  That said, the commands were
deliberately renamed in svn because CVS was considered largely insane.

Have fun,

Avery

On Wed, Jun 25, 2008 at 04:04:47PM -0400, Avery Pennarun wrote:

How about making "git checkout" default to HEAD if no revision is
supplied?  There's precedent for this in, say, git-diff (and I think a
few others).

Incidentally, "checkout <filename>" was also the way to do a revert
operation in CVS.  And the way to switch branches, too, iirc.  So git
isn't being too unusual here.  That said, the commands were
deliberately renamed in svn because CVS was considered largely insane.

The one thing I would worry about is the potential ambiguity if you do
something like "git checkout FOOBAR", and FOOBAR was both a branch
name as well as a file name.  How should it be interpreted?  I'd argue
the real problem was we conflated two distinct operations: "switching
to a new branch", and "reverting a file" to the same name, checkout.

Hence the suggestion to add a new command, "git revert-file", where
there would be no ambiguity.

							- Ted

On Wed, Jun 25, 2008 at 04:38:22PM -0400, Theodore Tso wrote:

On Wed, Jun 25, 2008 at 04:04:47PM -0400, Avery Pennarun wrote:

quoted

How about making "git checkout" default to HEAD if no revision is
supplied?  There's precedent for this in, say, git-diff (and I think a
few others).

Incidentally, "checkout <filename>" was also the way to do a revert
operation in CVS.  And the way to switch branches, too, iirc.  So git
isn't being too unusual here.  That said, the commands were
deliberately renamed in svn because CVS was considered largely insane.

The one thing I would worry about is the potential ambiguity if you do
something like "git checkout FOOBAR", and FOOBAR was both a branch
name as well as a file name.  How should it be interpreted?  I'd argue
the real problem was we conflated two distinct operations: "switching
to a new branch", and "reverting a file" to the same name, checkout.

Hence the suggestion to add a new command, "git revert-file", where
there would be no ambiguity.

Just to chime in, this reminds me of Cogito - it had cg-switch for
switching branches (like git checkout) and cg-restore for restoring
files in working copy (like git checkout, too; but you would pass -f if
you wanted to overwrite existing copy).

(Though, Cogito didn't quite get it right either since it tried to
overload cg-switch with the git branch functionality of creating new
branches. I still didn't quite come in terms with any UI model of the
branches I know about.)

-- 
				Petr "Pasky" Baudis
The last good thing written in C++ was the Pachelbel Canon. -- J. Olson

Hi,

On Thu, 26 Jun 2008, Petr Baudis wrote:

On Wed, Jun 25, 2008 at 04:38:22PM -0400, Theodore Tso wrote:

quoted

On Wed, Jun 25, 2008 at 04:04:47PM -0400, Avery Pennarun wrote:

quoted

How about making "git checkout" default to HEAD if no revision is 
supplied?  There's precedent for this in, say, git-diff (and I think 
a few others).

Incidentally, "checkout <filename>" was also the way to do a revert 
operation in CVS.  And the way to switch branches, too, iirc.  So 
git isn't being too unusual here.  That said, the commands were 
deliberately renamed in svn because CVS was considered largely 
insane.

The one thing I would worry about is the potential ambiguity if you do 
something like "git checkout FOOBAR", and FOOBAR was both a branch 
name as well as a file name.  How should it be interpreted?  I'd argue 
the real problem was we conflated two distinct operations: "switching 
to a new branch", and "reverting a file" to the same name, checkout.

Hence the suggestion to add a new command, "git revert-file", where 
there would be no ambiguity.

Just to chime in, this reminds me of Cogito - it had cg-switch for
switching branches (like git checkout) and cg-restore for restoring
files in working copy (like git checkout, too; but you would pass -f if
you wanted to overwrite existing copy).

Yeah, I was kinda disappointed that this part of Cogito never was picked 
up by Git "core".

I really liked the fact that Cogito was a test-bed for UI enhancements, 
and miss it a bit.  It was nice how it drove the UI enhancements of Git, 
and I am a little sad that Cogito was discontinued.  (And no, I do not see 
any contender picking up the task of driving Git's UI in the right 
direction.)
 

(Though, Cogito didn't quite get it right either since it tried to 
overload cg-switch with the git branch functionality of creating new 
branches. I still didn't quite come in terms with any UI model of the 
branches I know about.)

To the contrary, I think that "git branch --create <branch>" _should_ 
switch to the newly created branch.  That is what users expect, and Cogito 
got that right.

Ciao,
Dscho

On 2008.06.25 10:22:08 -0700, Junio C Hamano wrote:

Theodore Tso [off-list ref] writes:

quoted

I used to argue for this, but gave up, because no one seemed to agree
with me.  So now I just have the following in
/home/tytso/bin/git-revert-file and I am very happy:

#!/bin/sh
#
prefix=$(git rev-parse --show-prefix)

for i in $*
do
        git show HEAD:$prefix$i > $i
done

Isn't that this?

        #!/bin/sh
        exec git checkout HEAD -- "$@"

I thought so at first, too, but there's one difference. Ted's version
doesn't affect the index, while yours does. Of course I cannot tell if
Ted actually intended not to touch the index ;-)

Björn

Hi,

On Thu, 26 Jun 2008, Björn Steinbrink wrote:

On 2008.06.25 10:22:08 -0700, Junio C Hamano wrote:

quoted

Theodore Tso [off-list ref] writes:

quoted

I used to argue for this, but gave up, because no one seemed to agree
with me.  So now I just have the following in
/home/tytso/bin/git-revert-file and I am very happy:

#!/bin/sh
#
prefix=$(git rev-parse --show-prefix)

for i in $*
do
        git show HEAD:$prefix$i > $i
done

Isn't that this?

        #!/bin/sh
        exec git checkout HEAD -- "$@"

I thought so at first, too, but there's one difference. Ted's version
doesn't affect the index, while yours does. Of course I cannot tell if
Ted actually intended not to touch the index ;-)

While we are nit-picking: Ted's version does not respect autocrlf, while 
Junio's does.

Oh, and Junio's version works with spaces and other funny stuff in file 
names, while Ted's does not.

Oh, and error checking is correct in Junio's version.

I am sure there are more differences.

Ciao,
Dscho

On 2008.06.26 13:07:40 +0100, Johannes Schindelin wrote:

On Thu, 26 Jun 2008, Björn Steinbrink wrote:

quoted

On 2008.06.25 10:22:08 -0700, Junio C Hamano wrote:

quoted

Theodore Tso [off-list ref] writes:

quoted

I used to argue for this, but gave up, because no one seemed to agree
with me.  So now I just have the following in
/home/tytso/bin/git-revert-file and I am very happy:

#!/bin/sh
#
prefix=$(git rev-parse --show-prefix)

for i in $*
do
        git show HEAD:$prefix$i > $i
done

Isn't that this?

        #!/bin/sh
        exec git checkout HEAD -- "$@"

I thought so at first, too, but there's one difference. Ted's version
doesn't affect the index, while yours does. Of course I cannot tell if
Ted actually intended not to touch the index ;-)

While we are nit-picking: Ted's version does not respect autocrlf, while 
Junio's does.

Oh, and Junio's version works with spaces and other funny stuff in file 
names, while Ted's does not.

Oh, and error checking is correct in Junio's version.

I am sure there are more differences.

I didn't intend to nit-pick, sorry if it looked like that. Not touching
the index might have been a conscious decision, but obviously I must
have missed some email that made it clear that it was intended to also
revert the index entry. Very sorry...

Thanks for the information on autocrlf though, didn't know that show
doesn't care about that.

Björn

On 6/26/08, Johannes Schindelin [off-list ref] wrote:

While we are nit-picking: Ted's version does not respect autocrlf, while
 Junio's does.

Is it intentional that git-show doesn't respect autocrlf, or just an oversight?

Avery

Hi,

On Thu, 26 Jun 2008, Avery Pennarun wrote:

On 6/26/08, Johannes Schindelin [off-list ref] wrote:

quoted

While we are nit-picking: Ted's version does not respect autocrlf, 
while Junio's does.

Is it intentional that git-show doesn't respect autocrlf, or just an 
oversight?

Funny.  I seem to have answered exactly the same question a few days ago.

"git show" is meant to show the contents of an object.  It does not 
operate on a working directory.  It does not even _need_ a working 
directory.

So, no, it is _not_ an oversight.

Hth,
Dscho