Re: Submodule/contents conflict

From: Jeff King <peff@peff.net>
Date: Apr 25, 2017, 03:22 UTC
Message-ID: <20170425032242.wlmqrkgkeg3ytfle@sigill.intra.peff.net>
In-Reply-To: <CAGZ79kZDzuSHw4siSkiekw73bBq9R8gg_R+a7NyNUG6bYxc2Og@mail.gmail.com>

On Mon, Apr 24, 2017 at 04:43:28PM -0700, Stefan Beller wrote:

Show 11 quoted lines

> >> 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.

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.

> > 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