Re: [RFC] git checkout $tree -- $path always rewrites files

From: Jeff King <peff@peff.net>
Date: Nov 13, 2014, 19:26 UTC
Message-ID: <20141113192655.GA3413@peff.net>
In-Reply-To: <xmqqbnoa29ps.fsf@gitster.dls.corp.google.com>

On Thu, Nov 13, 2014 at 11:15:27AM -0800, Junio C Hamano wrote:

Show 15 quoted lines

> > diff --git a/builtin/checkout.c b/builtin/checkout.c
> > index 5410dac..67cab4e 100644
> > --- a/builtin/checkout.c
> > +++ b/builtin/checkout.c
> > @@ -65,21 +65,40 @@ static int post_checkout_hook(struct commit *old, struct commit *new,
> >  static int update_some(const unsigned char *sha1, const char *base, int baselen,
> >  		const char *pathname, unsigned mode, int stage, void *context)
> >  {
> > ...
> >  }
> 
> Makes sense, including the use of strbuf (otherwise you would
> allocate ce and then discard when it turns out that it is not
> needed, which is probably with the same allocation pressure, but
> looks uglier).

Exactly. Constructing it in ce->name does save you an allocation/memcpy in the case that we actually use the new entry, but I thought it would look weirder. It probably doesn't matter much either way, so I tried to write the most obvious thing.

(I also experimented with using make_cache_entry at one point, which requires the strbuf; some of my thinking on what looks reasonable may be left over from that approach).

Show 14 quoted lines

> > +test_expect_success 'do not touch files that are already up-to-date' '
> > +	git reset --hard &&
> > +	echo one >file1 &&
> > +	echo two >file2 &&
> > +	git add file1 file2 &&
> > +	git commit -m base &&
> > +	echo modified >file1 &&
> > +	test-chmtime =1000000000 file2 &&
> 
> Is the idea behind the hardcoded timestamp that this is sufficiently
> old (Sep 2001) that we will not get in trouble comparing with the
> real timestamp we get from the filesystem (which will definitely newer
> than that anyway) no matter when we run this test (unless you have a
> time-machine, that is)?

I didn't actually calculate what the timestamp was. The important thing is that it is not the timestamp that your system would give to the file if git-checkout opened and rewrote it. :)

I initially used "123", but was worried that would cause weird portability problems on systems. So I opted for something closer to "normal", but in the past. I think it is fine (modulo time machines), but I'd be happy to put in some more obvious sentinel, too.

And the worst case if you did have a time machine is that we might accidentally declare a buggy git to be correct (racily!). I can live with that, but I guess you could use a relative value (like "-10000") instead of a fixed sentinel (but then you'd have to record it for the "expect" check).

-Peff