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
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
From: Joel Becker <hidden> Date: 2016-06-15 22:42:16
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
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:42:16
Hi,
On Mon, 9 Jan 2006, Joel Becker wrote:
On Mon, Jan 09, 2006 at 01:46:38PM -0800, Junio C Hamano wrote:
quoted
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
From: Alex Riesen <hidden> Date: 2016-06-15 22:42:16
On 1/10/06, Johannes Schindelin [off-list ref] wrote:
quoted
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
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:42:16
Hi,
On Tue, 10 Jan 2006, Alex Riesen wrote:
On 1/10/06, Johannes Schindelin [off-list ref] wrote:
quoted
quoted
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
From: Alex Riesen <hidden> Date: 2016-06-15 22:42:16
On 1/10/06, Johannes Schindelin [off-list ref] wrote:
quoted
quoted
quoted
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?
From: Junio C Hamano <hidden> Date: 2016-06-15 22:42:17
lamikr [off-list ref] 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.