From: "Philip Oakley" <philipoakley@iee.org>
To: "Junio C Hamano" <gitster@pobox.com>
Cc: "Christoph Michelbach" <michelbach94@gmail.com>,
"Git Mailing List" <git@vger.kernel.org>
Subject: Re: [PATCH] Documentation/git-checkout: make doc. of checkout <tree-ish> clearer
Date: Wed, 19 Apr 2017 08:32:08 +0100 [thread overview]
Message-ID: <AC79ED43D69A4063B2F30AE43B1AEE63@PhilipOakley> (raw)
In-Reply-To: xmqqa87eimje.fsf@gitster.mtv.corp.google.com
From: "Junio C Hamano" <gitster@pobox.com> Sent: Tuesday, April 18, 2017
1:31 AM
> "Philip Oakley" <philipoakley@iee.org> writes:
>
>>>> If we'd created and added a file d just before the checkout, what
>>>> should
>>>> have happened to d, and why?
>>>
>>> I understand what the command does. It behaves perfectly as I expected
>>> it to. I did not find this script but wrote it to demonstrate that what
>>> the documentation says is different from how it behaves after having
>>> read what the documentation says it should do and noticing that that's
>>> not how I expected it to work from experience.
>>>
>>> What it really does is to copy all files described by the given paths
>>> from the given tree-ish to the working directory. Or at least that's my
>>> expectation of what it does.
>>>
>>> The documentation, however, says that the given paths are *restored*.
>>> This is different.
>>
>> I don't see that difference in the phrase *restored*, compared to your
>> 'copy all files described by the given paths'. Could you explain a
>> little more?
>
> I am obviously not Christoph, and I was the one that defined how
> "checkout <tree> -- <pathspec>" should work, but when you say
> "restore" (which is not what I wrote ;-)) it is fair to expect lack
> of 'd' could also be "restored", in addition to path that was in the
> directory.
>
> Obviously, "grab all paths that match <pathspec> out of <tree>, add
> them to the index and copy them out to the working tree" will never
> be able to _restore_ the lack of 'd', even it may match the
> <pathspec> being used to do this checkout, by removing it from the
> current index and the working tree.
>
My attempt at asking about an additional file 'd' ended up being a bit of a
red herring as it went off at a tangent.
Hopefully Christoph will hang in to help clarify the original issue. I think
I'm getting a sense of the potential confusion between the different
messages Git sends out, and which one is the right one here. On the one hand
Git promotes the two step staging area approach, but on the other hand the
checkout of a file suggests IIUC that all checkouts will end up as staged
revisions (one step only).
Philip
next prev parent reply other threads:[~2017-04-19 7:32 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-15 20:17 [PATCH] Documentation/git-checkout: make doc. of checkout <tree-ish> clearer Christoph Michelbach
2017-04-15 23:28 ` Philip Oakley
2017-04-16 13:01 ` Christoph Michelbach
2017-04-16 18:03 ` Philip Oakley
2017-04-16 18:51 ` Christoph Michelbach
2017-04-16 21:25 ` Philip Oakley
2017-04-16 22:06 ` Christoph Michelbach
2017-04-17 16:04 ` Philip Oakley
[not found] ` <1492452173.11708.22.camel@gmail.com>
2017-04-17 20:59 ` Philip Oakley
2017-04-18 0:31 ` Junio C Hamano
2017-04-18 12:26 ` Christoph Michelbach
2017-04-19 1:40 ` Junio C Hamano
2017-04-22 17:12 ` Christoph Michelbach
2017-04-24 1:55 ` Junio C Hamano
2017-04-24 12:24 ` Christoph Michelbach
2017-04-24 12:46 ` Christoph Michelbach
2017-04-25 1:35 ` Junio C Hamano
2017-04-25 9:11 ` Christoph Michelbach
2017-04-19 7:32 ` Philip Oakley [this message]
2017-04-18 11:50 ` Christoph Michelbach
2017-04-18 0:26 ` Junio C Hamano
2017-04-18 12:02 ` Christoph Michelbach
2017-04-19 8:14 ` Philip Oakley
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=AC79ED43D69A4063B2F30AE43B1AEE63@PhilipOakley \
--to=philipoakley@iee.org \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=michelbach94@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox