Torsten Bögershausen tboegi at web.de writes:
Do you think you can write a patch to improve the documentation ?
Here is my attempt, but it is only a starting point.
diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
index d263a56..ee25354 100644
---
On Fri, Jun 5, 2015 at 4:32 PM, Ed Avis e...@waniasset.com wrote:
Torsten Bögershausen tboegi at web.de writes:
Do you think you can write a patch to improve the documentation ?
Here is my attempt, but it is only a starting point.
diff --git a/Documentation/git-checkout.txt
Eric Sunshine sunsh...@sunshineco.com writes:
...
Again:
...`hello.c` will also be restored,...
because the file globbing is used to match entries in the index
(not in the working tree by the shell).
Thanks for a thorough review. I agree with all the comments and
suggestions you
I'm not attached to the wording changes posted earlier. As I said, it is
only a starting point.
I do feel that 'git checkout PATH' is rather a dangerous operation, and
moreover a surprisingly dangerous one, since 'git checkout BRANCH' is
careful not to lose local changes, as are other common
On Fri, Jun 5, 2015 at 5:32 AM, Ed Avis e...@waniasset.com wrote:
Torsten Bögershausen tboegi at web.de writes:
Do you think you can write a patch to improve the documentation ?
Here is my attempt, but it is only a starting point.
diff --git a/Documentation/git-checkout.txt
On Fri, Jun 5, 2015 at 1:44 PM, Eric Sunshine sunsh...@sunshineco.com wrote:
On Fri, Jun 5, 2015 at 5:32 AM, Ed Avis e...@waniasset.com wrote:
Torsten Bögershausen tboegi at web.de writes:
Do you think you can write a patch to improve the documentation ?
Here is my attempt, but it is only a
Stefan Beller sbeller at google.com writes:
So in one mode, we do actually warn about contents going missing, and the
other mode is designed to actually make things go missing without any
warning.
I think this is a big part of the issue. Two rather different operations
are given the name
Ed Avis eda at waniasset.com writes:
Julio H. asked how I had learned to run 'git checkout .'.
Sorry it was Torsten B. who asked that. But yes, I think it was just word
of mouth.
--
Ed Avis e...@waniasset.com
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a
Kevin Daudt me at ikke.info writes:
If people execute git checkout . as a habbit
without thinking, they will soon train to do git checkout -f . without
thinking, and then you still have the same problem.
I don't quite agree; you only learn to use the -f flag if the plain command
doesn't do what
On Wed, Jun 3, 2015 at 5:29 PM, Junio C Hamano gits...@pobox.com wrote:
[snip]
[Footnote]
*1* In the context of this discussion, after screwing up the change
in hello.c, instead of expressing the wish to recover and to
start from scratch in two separate commands, i.e.
rm
On 2015-06-04 13.00, Ed Avis wrote:
Updates files in the working tree to match...
I think that this had been written with
git checkout branch in mind, which is different
from git checkout -- paths (or git checkout .)
Do you think you can write a patch to improve the documentation ?
--
From: Ed Avis e...@waniasset.com
Sent: Wednesday, June 03, 2015 10:55 AM
Jeff King peff at peff.net writes:
I would say the more usual way to use checkout like this
is to give specific paths. I.e., run git status, say oh, I need to
restore the contents of 'foo', but not 'bar', and run git
On Wed, Jun 03, 2015 at 10:32:40AM -0700, Junio C Hamano wrote:
git checkout $paths (and you can give . for $paths to mean
everything) is akin to cp -R $elsewhere/$path . to restore the
working tree copies from somewhere else.
Ouch, 'git checkout .' overwrote what was in my working tree is
On Wed, Jun 03, 2015 at 09:55:05AM +, Ed Avis wrote:
Jeff King peff at peff.net writes:
If my personal experience is anything to go by, newcomers may fall into the
habit of running 'git checkout .' to restore missing files. In the old days
I would often delete a file and then run 'cvs
On June 3, 2015 3:06 PM Jeff King wrote:
On Wed, Jun 03, 2015 at 10:32:40AM -0700, Junio C Hamano wrote:
git checkout $paths (and you can give . for $paths to mean
everything) is akin to cp -R $elsewhere/$path . to restore the
working tree copies from somewhere else.
Ouch, 'git checkout
On 2015-06-03 11.55, Ed Avis wrote:
Jeff King peff at peff.net writes:
I would say the more usual way to use checkout like this
is to give specific paths. I.e., run git status, say oh, I need to
restore the contents of 'foo', but not 'bar', and run git checkout
foo. That works regardless of
Jeff King p...@peff.net writes:
On Wed, Jun 03, 2015 at 10:32:40AM -0700, Junio C Hamano wrote:
Yeah, I'd say cp -i is the closest thing. I don't have a problem with
adding that, but I'd really hate for it to be the default (just as I
find distros which alias rm='rm -i annoying).
Oh, no
Jeff King peff at peff.net writes:
I would say the more usual way to use checkout like this
is to give specific paths. I.e., run git status, say oh, I need to
restore the contents of 'foo', but not 'bar', and run git checkout
foo. That works regardless of the type of change to foo and bar.
That
On Wed, Jun 03, 2015 at 08:50:44AM +, Ed Avis wrote:
Currently a plain 'git checkout .' will revert any local changes, e.g.
% mkdir test
% cd test
% git init
Initialized empty Git repository in /home/eda/test/.git/
% echo hello foo
% git add foo
% git
On Wed, Jun 03, 2015 at 09:21:59AM +, Ed Avis wrote:
I had expected that 'git checkout .' would fix up my working tree to make it
match the repository (in this case, the current revision of the master
branch).
It did. :)
The user interface might be something like:
% git checkout .
I had expected that 'git checkout .' would fix up my working tree to make it
match the repository (in this case, the current revision of the master
branch). When I originally ran it I had deleted a couple of files from the
working tree and wanted to restore them. However, I expected that if
On June 3, 2015 1:35 PM Junio C Hamano wrote:
Ed Avis e...@waniasset.com writes:
If my personal experience is anything to go by, newcomers may fall
into the habit of running 'git checkout .' to restore missing files.
Is that really true? It all depends on why you came to a situation to
have
Randall S. Becker rsbec...@nexbridge.com writes:
On June 3, 2015 1:35 PM Junio C Hamano wrote:
Is that really true? It all depends on why you came to a
situation to have missing files in the first place, I would
think, but git checkout $path is I messed up the version in
the working tree at
On June 3, 2015 2:11 PM Junio C Hamano wrote:
Randall S. Becker rsbec...@nexbridge.com writes:
On June 3, 2015 1:35 PM Junio C Hamano wrote:
Is that really true? It all depends on why you came to a situation
to have missing files in the first place, I would think, but git
checkout $path
Jeff King p...@peff.net writes:
If we want to introduce more safety here, I'd be inclined to perform the
operation by default, but give a better escape hatch. For example, by
creating a loose object for any file we're about to overwrite, and
possibly writing an entry into a log.
Can we
Ed Avis e...@waniasset.com writes:
If my personal experience is anything to go by, newcomers may fall into the
habit of running 'git checkout .' to restore missing files.
Is that really true? It all depends on why you came to a situation
to have missing files in the first place, I would
Maybe the expectation comes from the existing warnings when checking
out branches?
$ mkdir tmp cd tmp
$ git init
$ echo Hello foo
$ git add foo
$ git commit -am Hello
$ git branch next
$ echo world bar
$ git add bar
$ git commit -a -m World
$ git checkout
27 matches
Mail list logo
