undoing changes with git-checkout -f

undoing changes with git-checkout -f

[lamikr]

Hi

Can somebody tell have I understood git-checkout -f wrong as following
does not work as I thought
1) I clone git repo by using command

    git-clone rsync://source.mvista.com/git/linux-omap-2.6.git
linux-omap-2.6

2) I go to cloned repo and create there a new file
    cd linux-omap-2.6
    echo "test" > 1.txt

3) I want to undo the creation of 1.txt by using command
    git-checkout -f

but for some reason the 1.txt is still displayed in the root of
linux-omap-2.6 directory. (I have also tried "git-reset --hard" but
seems to have same effect)
What am I doing wrong?

Mika

Re: undoing changes with git-checkout -f

[Junio C Hamano]

lamikr <lamikr@cc.jyu.fi> writes:

> 1) I clone git repo by using command
>
>     git-clone rsync://source.mvista.com/git/linux-omap-2.6.git
> linux-omap-2.6

Please do not use rsync:// transport if possible (mvista might
only pubilsh via rsync:// and not git://, so it may not be your
fault).

> 2) I go to cloned repo and create there a new file
>     cd linux-omap-2.6
>     echo "test" > 1.txt
>
> 3) I want to undo the creation of 1.txt by using command
>     git-checkout -f
>
> but for some reason the 1.txt is still displayed in the root of
> linux-omap-2.6 directory. (I have also tried "git-reset --hard" but
> seems to have same effect)
> What am I doing wrong?

Nothing.  After the second step, git does not know anything
about 1.txt; if it is a part of something you wanted to
eventually commit, or it is some notes you took while perusing
the source and is precious even when you switch branches (even
though you would not commit it as part of the project) , so it
does not touch it.  After running "make", "checkout -f" does not
do "make clean" for you to remove *.o files either, for exactly
the same reason.

"git status" would tell you the file is "untracked".

If you did something like this:

	$ edit 1.txt
        $ git add 1.txt
        $ git reset --hard

"git reset --hard" would remove it, while "git checkout -f"
would leave the file behind.

BTW, please do not set Reply-To: (or Mail-Followup-To: for that
matter) to the list.  When I (or somebody else) want to reply
to you, especially in private, your Reply-To: header forces me
to manually rewrite the To: header MUA prepares for me.

I know why you do it --- you are on the list and otherwise you
would get duplicate messages, one from me directly and another
from the list.  I've seen other people do it, but IMNSHO it is a
bad practice.  Filter them on your end, and do not put extra
burden to others, please.  The only case mucking with the
addressee headers may be acceptable is to remove yourself from
CC: list when a list you are on is on the CC: list.

Re: undoing changes with git-checkout -f

[lamikr]

Junio C Hamano wrote:

>lamikr <lamikr@cc.jyu.fi> writes:
>
>  
>
>>1) I clone git repo by using command
>>
>>    git-clone rsync://source.mvista.com/git/linux-omap-2.6.git
>>linux-omap-2.6
>>    
>>
>
>Please do not use rsync:// transport if possible (mvista might
>only pubilsh via rsync:// and not git://, so it may not be your fault).
>  
>
Ok, I will send a message to maintainer. I was just pasting the address
from their instructions. (They were using cogito on top of git, but I
want to learn to use pure git commands first)

>Nothing.  After the second step, git does not know anything
>about 1.txt; if it is a part of something you wanted to
>eventually commit, or it is some notes you took while perusing
>the source and is precious even when you switch branches (even
>though you would not commit it as part of the project) , so it
>does not touch it.  After running "make", "checkout -f" does not
>do "make clean" for you to remove *.o files either, for exactly
>the same reason.
>
>"git status" would tell you the file is "untracked".
>
>If you did something like this:
>
>	$ edit 1.txt
>        $ git add 1.txt
>        $ git reset --hard
>
>"git reset --hard" would remove it, while "git checkout -f"
>would leave the file behind.
>  
>
Ok, so this describes the power difference between "checkout -f"
and "git-reset --hard" pretty well.

>BTW, please do not set Reply-To: (or Mail-Followup-To: for that
>matter) to the list.  When I (or somebody else) want to reply
>to you, especially in private, your Reply-To: header forces me
>to manually rewrite the To: header MUA prepares for me.
>
>I know why you do it --- you are on the list and otherwise you
>would get duplicate messages, one from me directly and another
>from the list.  I've seen other people do it, but IMNSHO it is a
>bad practice.  Filter them on your end, and do not put extra
>burden to others, please.  The only case mucking with the
>addressee headers may be acceptable is to remove yourself from
>CC: list when a list you are on is on the CC: list.
>  
>
Yes, I am a victim of graphical email reader aka "thunderbird".
But I will now remember to do this for vger mailing lists.

A little off topic, but I just wish that http mail archive apps like the
one used in
http://marc.theaimsgroup.com/?l=linux-kernel
could also offer possibility to filter duplicates away.

Mika

Re: undoing changes with git-checkout -f

[Joel Becker]

On Mon, Jan 09, 2006 at 01:46:38PM -0800, Junio C Hamano wrote:
> Please do not use rsync:// transport if possible (mvista might
> only pubilsh via rsync:// and not git://, so it may not be your
> fault).

	Can we teach the git:// fetch program to use CONNECT over HTTP
proxies?  rsync can do this, but git:// cannot, so firewalls that block
9418 mean we use rsync://
	I'm mostly offline this week or I'd take a stab at it.

Joel

-- 

"We will have to repent in this generation not merely for the
 vitriolic words and actions of the bad people, but for the 
 appalling silence of the good people."
	- Rev. Dr. Martin Luther King, Jr.

Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127

Re: undoing changes with git-checkout -f

[Junio C Hamano]

Joel Becker <Joel.Becker@oracle.com> writes:

> 	Can we teach the git:// fetch program to use CONNECT over HTTP
> proxies?  rsync can do this, but git:// cannot, so firewalls that block
> 9418 mean we use rsync://
> 	I'm mostly offline this week or I'd take a stab at it.

It's been there for quite some time, although I never liked the
way it interfaces with the outside world.

	$ cat .git/config
        [core]
                repositoryformatversion = 0
                filemode = true
                gitproxy = /usr/local/bin/tn-gw-nav-local
	$ cat /usr/local/bin/tn-gw-nav-local
        #!/bin/sh
	# Use squid running at localhost
        exec tn-gw-nav -H -h 127.0.0.1 -p 3128 "$1" "$2"
	$ grep SSL /etc/squid/squid.conf
        acl SSL_ports 443 563 9418 # https snntp git
        http_access deny CONNECT !SSL_ports
	$ git fetch --tags git://git.kernel.org/pub/scm/git/git.git/

It is a bit inconvenient that "git clone" wrapper cannot be used
on an existing repository, and without an existing repository
you cannot have .git/config. You could have the config file in
your site-wide template area, but admittably it is a bit
awkward.

Re: undoing changes with git-checkout -f

[Joel Becker]

[-- Attachment #1: Type: text/plain, Size: 1605 bytes --]

On Mon, Jan 09, 2006 at 09:57:40PM -0800, Junio C Hamano wrote:
> Joel Becker <Joel.Becker@oracle.com> writes:
> > 	Can we teach the git:// fetch program to use CONNECT over HTTP
> > proxies?  rsync can do this, but git:// cannot, so firewalls that block
> > 9418 mean we use rsync://
> > 	I'm mostly offline this week or I'd take a stab at it.
> 
> It's been there for quite some time, although I never liked the
> way it interfaces with the outside world.
> 

	Ugly snipped...

> It is a bit inconvenient that "git clone" wrapper cannot be used
> on an existing repository, and without an existing repository
> you cannot have .git/config. You could have the config file in
> your site-wide template area, but admittably it is a bit
> awkward.

	Here's what I did.  I modified the usual
ssh-tunnel-over-SSL-CONNECT script to honor http_proxy.  I've attached
it.  With this, I do as so:

	# cp git-tunnel.pl /usr/local/bin
	# export http_proxy="http://my-proxy.my.com:80/"
	# GIT_PROXY_COMMAND="/usr/local/bin/git-tunnel.pl" git clone git://git.kernel.org/pub/scm/... localsource
	# cd localsource
	# vi .git/config
		[core]
			gitproxy = /usr/local/bin/git-tunnel.pl

	This is working for me.  I'd really rather have the tunneling
code be part of connect.c, and have core.proxymethod=external use the
current core.gitproxy method and core.proxymethod=http use $http_proxy.
	But this will suffice for now :-)

Joel

-- 

Life's Little Instruction Book #198

	"Feed a stranger's expired parking meter."

Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127

[-- Attachment #2: git-tunnel.pl --]
[-- Type: text/x-perl, Size: 2667 bytes --]

#!/usr/bin/perl
#
# git-tunnel.pl	
#
# Usage: git-tunnel.pl ssl-proxy port destination_host port
#
# This script can be used by git as a "core.gitproxy" to 
# traverse a www-proxy/firewall that supports the http CONNECT 
# command described in
# http://home.netscape.com/newsref/std/tunneling_ssl.html
#
# It uses the http_proxy (or HTTP_PROXY) variable to determine the
# proxy to connect to.  Put the path to this script in the environment
# variable GIT_PROXY_COMMAND, or better yet, insert the core.gitproxy
# definition in .git/config.
#
#      .
#      .
#      [core]
#          gitproxy = /path/to/git-tunnel.pl
#      .
#      .
#
# Written by Urban Kaveus <urban@statt.ericsson.se>
# Modified to use http_proxy by Joel Becker <joel.becker@oracle.com>

use Socket;

# Parse command line arguments

if ( $#ARGV != 1 ) {
    print STDERR "Usage: $0 destination port\n";
    print STDERR $#ARGV, "\n";
    exit(1);
}

$proxy_url = $ENV{'http_proxy'};
if (!$proxy_url) {
    $proxy_url = $ENV{'HTTP_PROXY'};
}

$proxyport = 80;
if ($proxy_url =~ /^https?:\/\/([^:]+)\/$/) {
    $sslproxy = $1;
} elsif ($proxy_url =~ /^https?:\/\/([^:]+):([1-9][0-9]*)\/$/) {
    $sslproxy = $1;
    $proxyport = $2;
} else {
    print STDERR "Invalid proxy specification: \"$proxy_url\"\n";
    exit(1);
}

$destination = shift;
$destport    = shift;

# Set up network communication

($protocol) = (getprotobyname("tcp"))[2];
($proxyip)  = (gethostbyname($sslproxy))[4];
$localaddr  = pack('S n a4 x8', &AF_INET, 0, "\0\0\0\0");
$proxyaddr  = pack('S n a4 x8', &AF_INET, $proxyport, $proxyip);

socket (PROXY, &AF_INET, &SOCK_STREAM, $protocol) or
    die("Failed to create cocket");
bind (PROXY, $localaddr) or
    die("Failed to bind socket");
connect (PROXY, $proxyaddr) or
    die("Failed to connect to $sslproxy port $proxyport");

# Force flushing of socket buffers

select (PROXY);  $| = 1; 
select (STDOUT); $| = 1;

# Send a "CONNECT" command to proxy:

print PROXY "CONNECT $destination:$destport HTTP/1.1\r\n\r\n";

# Wait for HTTP status code, bail out if you don't get back a 2xx code.

$_ = <PROXY>;
($status) = (split())[1];

die("Received a bad status code \"$status\" from proxy server") 
    if ( int($status/100) != 2 );

# Skip through remaining part of MIME header

while(<PROXY>) {
    chomp;   # Strip <LF>
    last if /^[\r]*$/;		# Empty line or a single <CR> left
}

# Start copying packets in both directions.

if($child = fork) { # Parent process
    while (sysread(STDIN,$_,4096)) {
        print PROXY;
    }
    sleep 2;
    kill(15,$child) if $child;
}

else { # Child process
    while (sysread(PROXY,$_,4096)) {
        print STDOUT;
    }
}

Re: undoing changes with git-checkout -f

[Joel Becker]

[-- Attachment #1: Type: text/plain, Size: 533 bytes --]

On Mon, Jan 09, 2006 at 10:32:47PM -0800, Joel Becker wrote:
> 	Here's what I did.  I modified the usual
> ssh-tunnel-over-SSL-CONNECT script to honor http_proxy.  I've attached
> it.  With this, I do as so:

	Bug in the script closing one side of the connection.  Corrected
version attached.

Joel

-- 

"I'm drifting and drifting
 Just like a ship out on the sea.
 Cause I ain't got nobody, baby,
 In this world to care for me."

Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127

[-- Attachment #2: git-tunnel.pl --]
[-- Type: text/x-perl, Size: 2715 bytes --]

#!/usr/bin/perl
#
# git-tunnel.pl	
#
# Usage: git-tunnel.pl ssl-proxy port destination_host port
#
# This script can be used by git as a "core.gitproxy" to 
# traverse a www-proxy/firewall that supports the http CONNECT 
# command described in
# http://home.netscape.com/newsref/std/tunneling_ssl.html
#
# It uses the http_proxy (or HTTP_PROXY) variable to determine the
# proxy to connect to.  Put the path to this script in the environment
# variable GIT_PROXY_COMMAND, or better yet, insert the core.gitproxy
# definition in .git/config.
#
#      .
#      .
#      [core]
#          gitproxy = /path/to/git-tunnel.pl
#      .
#      .
#
# Written by Urban Kaveus <urban@statt.ericsson.se>
# Modified to use http_proxy by Joel Becker <joel.becker@oracle.com>

use Socket;

# Parse command line arguments

if ( $#ARGV != 1 ) {
    print STDERR "Usage: $0 destination port\n";
    print STDERR $#ARGV, "\n";
    exit(1);
}

$proxy_url = $ENV{'http_proxy'};
if (!$proxy_url) {
    $proxy_url = $ENV{'HTTP_PROXY'};
}

$proxyport = 80;
if ($proxy_url =~ /^https?:\/\/([^:]+)\/$/) {
    $sslproxy = $1;
} elsif ($proxy_url =~ /^https?:\/\/([^:]+):([1-9][0-9]*)\/$/) {
    $sslproxy = $1;
    $proxyport = $2;
} else {
    print STDERR "Invalid proxy specification: \"$proxy_url\"\n";
    exit(1);
}

$destination = shift;
$destport    = shift;

# Set up network communication

($protocol) = (getprotobyname("tcp"))[2];
($proxyip)  = (gethostbyname($sslproxy))[4];
$localaddr  = pack('S n a4 x8', &AF_INET, 0, "\0\0\0\0");
$proxyaddr  = pack('S n a4 x8', &AF_INET, $proxyport, $proxyip);

socket (PROXY, &AF_INET, &SOCK_STREAM, $protocol) or
    die("Failed to create cocket");
bind (PROXY, $localaddr) or
    die("Failed to bind socket");
connect (PROXY, $proxyaddr) or
    die("Failed to connect to $sslproxy port $proxyport");

# Force flushing of socket buffers

select (PROXY);  $| = 1; 
select (STDOUT); $| = 1;

# Send a "CONNECT" command to proxy:

print PROXY "CONNECT $destination:$destport HTTP/1.1\r\n\r\n";

# Wait for HTTP status code, bail out if you don't get back a 2xx code.

$_ = <PROXY>;
($status) = (split())[1];

die("Received a bad status code \"$status\" from proxy server") 
    if ( int($status/100) != 2 );

# Skip through remaining part of MIME header

while(<PROXY>) {
    chomp;   # Strip <LF>
    last if /^[\r]*$/;		# Empty line or a single <CR> left
}

# Start copying packets in both directions.

$parent = $$;
if($child = fork) { # Parent process
    while (sysread(STDIN,$_,4096)) {
        print PROXY;
    }
    sleep 2;
    kill(15,$child) if $child;
}

else { # Child process
    while (sysread(PROXY,$_,4096)) {
        print STDOUT;
    }
    sleep 2;
    kill(15,$parent);
}

Re: undoing changes with git-checkout -f

[Junio C Hamano]

Joel Becker <Joel.Becker@oracle.com> writes:

> ...  I'd really rather have the tunneling
> code be part of connect.c,...

For the record, I was pushing for that, but that approach was
interrupted primarily by what this message implies:

    http://article.gmane.org/gmane.comp.version-control.git/10985

The thread that originally introduced the current proxy is here:

    http://thread.gmane.org/gmane.comp.version-control.git/11074

Re: undoing changes with git-checkout -f

[Joel Becker]

On Mon, Jan 09, 2006 at 11:42:24PM -0800, Junio C Hamano wrote:
> Joel Becker <Joel.Becker@oracle.com> writes:
> > ...  I'd really rather have the tunneling
> > code be part of connect.c,...
> 
> For the record, I was pushing for that, but that approach was
> interrupted primarily by what this message implies:
> 
>     http://article.gmane.org/gmane.comp.version-control.git/10985

	Yeah, we want to handle multiple things.  Well, I've got it
working with git-tunnel.pl, so I'm happy enough not to be using rsync://
:-)

Joel

-- 

Life's Little Instruction Book #139

	"Never deprive someone of hope; it might be all they have."

Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127

Re: undoing changes with git-checkout -f

[Johannes Schindelin]

Hi,

On Mon, 9 Jan 2006, Joel Becker wrote:

> On Mon, Jan 09, 2006 at 01:46:38PM -0800, Junio C Hamano wrote:
> > Please do not use rsync:// transport if possible (mvista might
> > only pubilsh via rsync:// and not git://, so it may not be your
> > fault).
> 
> 	Can we teach the git:// fetch program to use CONNECT over HTTP
> proxies?  rsync can do this, but git:// cannot, so firewalls that block
> 9418 mean we use rsync://

I think it is good and well with the proxy command support. Everybody can 
write a little script.

Otherwise, where would it end? If you include http_proxy functionality in 
git, why not also https_proxy functionality? And if that, why not 
IP-over-SMTP?

Hth,
Dscho

Re: undoing changes with git-checkout -f

[Alex Riesen]

On 1/10/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> >       Can we teach the git:// fetch program to use CONNECT over HTTP
> > proxies?  rsync can do this, but git:// cannot, so firewalls that block
> > 9418 mean we use rsync://
>
> I think it is good and well with the proxy command support. Everybody can
> write a little script.
>
> Otherwise, where would it end? If you include http_proxy functionality in
> git, why not also https_proxy functionality? And if that, why not

And, BTW, why not? It may as well stop here.

Re: undoing changes with git-checkout -f

[Johannes Schindelin]

Hi,

On Tue, 10 Jan 2006, Alex Riesen wrote:

> On 1/10/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > >       Can we teach the git:// fetch program to use CONNECT over HTTP
> > > proxies?  rsync can do this, but git:// cannot, so firewalls that block
> > > 9418 mean we use rsync://
> >
> > I think it is good and well with the proxy command support. Everybody can
> > write a little script.
> >
> > Otherwise, where would it end? If you include http_proxy functionality in
> > git, why not also https_proxy functionality? And if that, why not
> 
> And, BTW, why not? It may as well stop here.

Because it's not the purpose of git. It is the purpose of a tunnel. Let's 
not make the mistake of Microsoft here: integrate everything until 
everything breaks.

Ciao,
Dscho

Re: undoing changes with git-checkout -f

[Alex Riesen]

On 1/10/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > >       Can we teach the git:// fetch program to use CONNECT over HTTP
> > > > proxies?  rsync can do this, but git:// cannot, so firewalls that block
> > > > 9418 mean we use rsync://
> > >
> > > I think it is good and well with the proxy command support. Everybody can
> > > write a little script.
> > >
> > > Otherwise, where would it end? If you include http_proxy functionality in
> > > git, why not also https_proxy functionality? And if that, why not
> >
> > And, BTW, why not? It may as well stop here.
>
> Because it's not the purpose of git. It is the purpose of a tunnel. Let's
> not make the mistake of Microsoft here: integrate everything until
> everything breaks.

Of course, I do not propose to put the code into connect.c! Let it be
ip-tunnel.pl,
or something like that (which btw is really awkward to handle under a well-known
disabled OS).

But, it is not exactly standard tunnel, is it? I mean, can you use it
for something
else? If not, is there really a point _not_ to put it in the git
repository? As tunnel
script or program, or as an instruction file on how to setup a firewall?

Re: undoing changes with git-checkout -f

[lamikr]

Linus Torvalds wrote:

>You should realize that git _does_not_know_ about your file. You never 
>even told git about it. So git won't ever evenlook at it, much less delete 
>it.
>
>So when you do a "git checkout -f", what that does is to rewrite all the 
>files that git KNOWS about. Any files git doesn't know about will not ever 
>be touched. Your "1.txt" file might as well be an object file, for all git 
>knows. And git won't remove your object files or any other files that it 
>doesn't know.
>
>(Now, in all fairness, even if you had done "git add", I don't think git 
>will remove the file. If you committed the file and then checked out the 
>previous version, _then_ it would remove the committed file).
>  
>
Now that you say it, I got it, thanks. I expected earlier that git would
perform also the
remove of non-added files as other commands like "git-commit" are anyway
aware
if you have files in your working dir that have not yet added.

>If what you want to do is to clean the git directory of all files that git 
>doesn't know about, you can do that with
>
>	git-ls-files -z --others | xargs -0 rm --
>  
>
Thanks for the tip. I have now added alias git-reset-ff='git-ls-files -z
--others | xargs -0 rm --'
And git-reset-fff (forte fortissimo) would probably blow the whole hd
away :-)

Mika