From: Christoph Michelbach <michelbach94@gmail.com>
To: Philip Oakley <philipoakley@iee.org>
Cc: Git Mailing List <git@vger.kernel.org>
Subject: Re: [PATCH] Documentation/git-checkout: make doc. of checkout <tree-ish> clearer
Date: Tue, 18 Apr 2017 13:50:21 +0200 [thread overview]
Message-ID: <1492516221.5720.22.camel@gmail.com> (raw)
In-Reply-To: <5FD0803E166B4D2F9F64D8D21AC23EB3@PhilipOakley>
On Mon, 2017-04-17 at 21:59 +0100, Philip Oakley wrote:
> I've added back the list, as it was accidentally dropped.
Thanks. I'm sorry. I apparently pressed the wrong button in my emails
client. What I wrote is visible in your quote.
> From: "Christoph Michelbach" <michelbach94@gmail.com>
> > 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?
Suppose you have X. If you say X is restored to what it was half an hour
ago, I expect everything about X to be exactly as it was half an hour
ago. So if X is a file containing the text "Hello, world!", I expect
there to be a file (with the exact same file name) which contains the
text "Hello, world!", even if I changed that text in the mean time or
deleted the file entirely. If X is a folder which contains files, I
expect it to have the exact same contents as before. If there were 5
files in the folder half an hour ago, I expect there to be 5 files with
the same file names and the same content in each file, again, even if I
deleted, renamed, changed the contents of, or added files in the mean
time. This is, however, not the case. Suppose I renamed a file from
"foo" to "bar". Then there are 6 files, not 5. This is not how X was
half an hour ago.
If you, however, say that all files in the path X are copied back from
what they were half an hour ago, if X is a file, I expect the exact same
thing as before for it. And that's actually what happens in reality. But
if X is a folder, there's a difference: Because only the *files X
contains* are copied back – *not X itself* –, all the files in X which
do not occur in the state from half an hour ago, are unaffected. So now
I expect there to be a 6th file because there is no file "bar" in the
state from half an hour ago which could overwrite the file "bar" in the
working tree.
> > Yeah, definitely. There should be 2 separate entries for this.
> >
> > I think someone thought it was a good idea to make `<pathspec>...`
> > optional in the synopsis because `git checkout` behaves in that
> > special
> > way if a patch *or* paths are given. But then, of course, with both
> > `-
> > p|--patch` and `<pathspec>...` optional, the command is the same as
> > the
> > first variation, just with optional parameters -- but the
> > documentation
> > (correctly) says those variations should behave very differently
> > from
> > each other.
> >
> > I don't see how this can be avoided without having 2 separate
> > entries
> > for those cases.
> true.
So now we have to find someone who used that command with both a patch
and a tree-ish present a lot because I have no idea how that would
behave and don't even know why you would use it.
--
Christoph
next prev parent reply other threads:[~2017-04-18 11:50 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
2017-04-18 11:50 ` Christoph Michelbach [this message]
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1492516221.5720.22.camel@gmail.com \
--to=michelbach94@gmail.com \
--cc=git@vger.kernel.org \
--cc=philipoakley@iee.org \
/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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).