From: "Philip Oakley" <philipoakley@iee.org>
To: "Stefan Beller" <sbeller@google.com>, "Jeff King" <peff@peff.net>
Cc: "Orgad Shaneh" <orgads@gmail.com>,
"Dakota Hawkins" <dakotahawkins@gmail.com>,
"git" <git@vger.kernel.org>,
"Christoph Michelbach" <michelbach94@gmail.com>
Subject: Re: Submodule/contents conflict
Date: Tue, 25 Apr 2017 12:10:01 +0100 [thread overview]
Message-ID: <C3A8A88B8DDD468095B7FD256330EEF7@PhilipOakley> (raw)
In-Reply-To: CAGZ79kZDzuSHw4siSkiekw73bBq9R8gg_R+a7NyNUG6bYxc2Og@mail.gmail.com
From: "Stefan Beller" <sbeller@google.com>
> On Mon, Apr 24, 2017 at 4:33 PM, Philip Oakley <philipoakley@iee.org>
> wrote:
>
>> This is almost the same as just reported by 'vvs' [1]
>> https://public-inbox.org/git/CAM1zWBtfgHT=pT0pidQo1HD=DfrXLG3gNaUvs0vZKvYfG1BHFw@mail.gmail.com/,
>> originally on the 'git user' list
>> https://groups.google.com/forum/?hl=en#!topic/git-users/9ziZ6yq-BfU
>
> For this issue, +cc Jeff King due to this pointer:
>
>>> On the main list thare is a similar "issue" [1] regarding the
>>> expectation for `git checkout`,
>>> and importantly (for me) these collected views regarding the "Git Data
>>> Protection and
>>> Management Principles" is not within the Git documentation.
>>
>> Yes, that's an interesting point. What concerns me is that the commit
>> c5326bd62b7e168ba1339dacb7ee812d0fe98c7c which introduced this
>> into checkout isn't consistent with reset. Seems that nobody noticed this
>> before.
>
> It seems as if we'd want to see the code from
> c5326bd62b7e168ba1339dacb7ee812d0fe98c7c
> to be part of any worktree touching command, specifically reset?
>
>> It also has a similarity to
>> https://public-inbox.org/git/1492287435.14812.2.camel@gmail.com/
>> regarding
>> how checkout operates.
>
> This seems to be orthogonal to the original topic (no submodules, nor
> checkout
> bugs, just a doc update?)
At the moment that topic has ended up as an attempt at a documentation
update, but I think it may not succeed ynless there is clarity about the
(reported) underlying problem.
As I recall Christoph was using checkout to copy a file (e.g. a template
file) from an older commit/revision into his worktree, and was suprised that
this (git checkout <tree> <path>) also _staged_ the file, rather than simply
letting it be in a modified/untracked state.
It in a sense is the same issue of relating the worktree content to the
index status, though I think that checkout is acting as designed/intended.
I don't think that there is a command (is ther?) to do what Christoph hoped
for of not staging the new content (e.g. a template file), but the index
knowing/remembering its stat details, just in case.
The submodule case appears to be more about deciding if the content of
submodule's index should be considered for inclusion in the super project
prior to the checkout of the other branch's tree that is already unchanged
and in-place.
>
>
>> It does feel as if there are two slightly different optimisations that
>> could
>> be used when the desired file pre-exists in the worktree, but isn't
>> immediately known to the index.
>>
>
--
Philip
next prev parent reply other threads:[~2017-04-25 11:10 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-24 8:06 Submodule/contents conflict Orgad Shaneh
2017-04-24 17:40 ` Stefan Beller
2017-04-24 23:33 ` Philip Oakley
2017-04-24 23:43 ` Stefan Beller
2017-04-25 3:22 ` Jeff King
2017-04-25 3:39 ` Jeff King
2017-04-27 22:52 ` Philip Oakley
2017-04-28 8:30 ` Jeff King
2017-05-01 0:15 ` Junio C Hamano
2017-04-25 11:10 ` Philip Oakley [this message]
2017-04-26 2:51 ` Junio C Hamano
2017-04-26 17:41 ` Stefan Beller
2017-04-27 0:25 ` Junio C Hamano
2017-04-27 0:29 ` Junio C Hamano
2017-04-27 22:07 ` Philip Oakley
2017-04-28 2:08 ` Junio C Hamano
2017-04-25 2:12 ` Junio C Hamano
2017-04-25 15:57 ` Stefan Beller
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=C3A8A88B8DDD468095B7FD256330EEF7@PhilipOakley \
--to=philipoakley@iee.org \
--cc=dakotahawkins@gmail.com \
--cc=git@vger.kernel.org \
--cc=michelbach94@gmail.com \
--cc=orgads@gmail.com \
--cc=peff@peff.net \
--cc=sbeller@google.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.
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).