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 comm
On Fri, Jun 5, 2015 at 1:44 PM, Eric Sunshine wrote:
> On Fri, Jun 5, 2015 at 5:32 AM, Ed Avis wrote:
>> Torsten Bögershausen 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/Documen
Eric Sunshine 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 gave. Also, Ed,
On Fri, Jun 5, 2015 at 5:32 AM, Ed Avis wrote:
> Torsten Bögershausen 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
> ind
On Fri, Jun 5, 2015 at 4:32 PM, Ed Avis wrote:
> Torsten Bögershausen 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
> i
Torsten Bögershausen 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
--- a/Documentation/git-checkou
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 " in mind, which is different
from "git checkout -- " (or "git checkout .")
Do you think you can write a patch to improve the documentation ?
--
To
Ed Avis 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vg
Kevin Daudt 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 yo
Stefan Beller 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 'checkout', a
On Wed, Jun 3, 2015 at 5:29 PM, Junio C Hamano 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 hello.c && upd
Jeff King 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 question
From: "Ed Avis"
Sent: Wednesday, June 03, 2015 10:55 AM
Jeff King 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
On Wed, Jun 03, 2015 at 09:55:05AM +, Ed Avis wrote:
> Jeff King 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 u
On 2015-06-03 11.55, Ed Avis wrote:
> Jeff King 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 re
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.
> >
> > "
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 wo
On June 3, 2015 2:11 PM Junio C Hamano wrote:
> "Randall S. Becker" 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
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
"Randall S. Becker" 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 $path,
On June 3, 2015 1:35 PM Junio C Hamano wrote:
> Ed Avis 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 f
Ed Avis 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 think, but "git
chec
Jeff King 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 borrow the idea
Jeff King 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
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 doing
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
>
27 matches
Mail list logo
