Re: Submodule/contents conflict

["Philip Oakley" <philipoakley@iee.org>]

From: "Jeff King" <peff@peff.net> Sent: Tuesday, April 25, 2017 4:22 AM

Just catching up - sorry it's late..
> On Mon, Apr 24, 2017 at 04:43:28PM -0700, Stefan Beller wrote:
>
>> >> 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?
>
> Note that that commit is just about "git checkout <commit> -- <paths>".
> The matching reset command, "git reset <commit> -- <paths>" does handle
> this the same way. Or at least I claimed so here:
>
>  http://public-inbox.org/git/20141107081324.GA19845@peff.net/
>
> and that is what I modeled the code in c5326bd62b after.
>
> But note that none of that should ever affect _what_ gets checked out at
> a file or content level. It may only affect the timestamps on the
> resulting files. And I think those timestamps are not something Git
> makes any promises about.

It's not actually clear to users what Git promises in cases like this which 
confuses user expectations - the make file issue does appear to come up 
quite often.
>
> So if Git can elide a write and keep a timestamp up to date, that is a
> great optimization and we should do that. But from an outside viewer's
> perspective, we guarantee nothing. We might choose to rewrite a
> stat-dirty file (updating its timestamp) rather than read its contents
> to see if it might have the same content that we're about to write. And
> the file may look stat dirty only because of the racy-git file/index
> timestamp problem, even if it wasn't actually modified.

I'm not sure how in this case we would get the stat-dirty state? We should 
be able to determine that the file has existed, as originally checked out, 
for some while (i.e. past the racy FS time) and is unmodified, so that as 
long as the original checkout OID and the required new OID are the same we 
should be able to avoid the file overwrite (or merge).

It would require that the now time be used as a stand-in for the new OID 
file's stat time (given the object store doesn't store date stamps for 
files) to check for the racy-git situation. These negative information 
scenarios can be tricky.
>
>> > It also has a similarity to
>> > https://public-inbox.org/git/1492287435.14812.2.camel@gmail.com/ 
>> > regarding
>> > how checkout operates.
>
> I didn't look too deeply into this one, but it really looks like
> somebody caring too much about when git needs to write (and I'd suspect
> it's impacted by the racy-git thing, too).
>
> -Peff
>
--
Philip