From: "Jeff King" <peff@xxxxxxxx> 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@xxxxxxxx/
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@xxxxxxxxx/
> 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