Re: [RFC PATCH] checkout: Force matching mtime between files

2018-05-05 Thread Junio C Hamano
Jeff King writes: > The files in your checkout would all be consistent, but they might be > inconsistent with other files _not_ created by Git (e.g., one might be > saved in your editor). Now you may have introduced skew that cause > "make" to do the wrong thing, because your

Re: [RFC PATCH] checkout: Force matching mtime between files

2018-05-05 Thread Jeff King
On Fri, Apr 13, 2018 at 07:01:29PM +0200, Michał Górny wrote: > In order to avoid unnecessary cache mismatches, force a matching mtime > between all files created by a single checkout action. This seems to be > the best course of action. Matching mtimes do not trigger cache > updates. They

Re: [RFC PATCH] checkout: Force matching mtime between files

2018-04-30 Thread Duy Nguyen
On Mon, Apr 30, 2018 at 1:56 AM, Junio C Hamano wrote: > Duy Nguyen writes: > >> Target revision should be available in the index. But this gives me an >> idea to another thing that bugs me: sending the list to the hook means >> I have to deal with separator

Re: [RFC PATCH] checkout: Force matching mtime between files

2018-04-29 Thread Junio C Hamano
Duy Nguyen writes: > Target revision should be available in the index. But this gives me an > idea to another thing that bugs me: sending the list to the hook means > I have to deal with separator (\n or NUL?) or escaping. This mentions > of index makes me take a different

Re: [RFC PATCH] checkout: Force matching mtime between files

2018-04-29 Thread Junio C Hamano
Elijah Newren writes: > Here's a crazy idea -- maybe instead of a list of pathspecs you just > provide the timestamp of when git checkout started. Then the hook > could walk the tree, find all files with modification times at least > that late, and modify them all back to the

Re: [RFC PATCH] checkout: Force matching mtime between files

2018-04-28 Thread Michał Górny
W dniu sob, 28.04.2018 o godzinie 16∶23 +0200, użytkownik Duy Nguyen napisał: > On Thu, Apr 26, 2018 at 4:46 PM, Michał Górny wrote: > > For the record, we're using this with ebuilds and respective cache files > > (which are expensive to generate). We are using separate

Re: [RFC PATCH] checkout: Force matching mtime between files

2018-04-28 Thread Duy Nguyen
On Thu, Apr 26, 2018 at 4:46 PM, Michał Górny wrote: > For the record, we're using this with ebuilds and respective cache files > (which are expensive to generate). We are using separate repository > which combines sources and cache files to keep the development > repository

Re: [RFC PATCH] checkout: Force matching mtime between files

2018-04-28 Thread Duy Nguyen
On Fri, Apr 27, 2018 at 11:08 PM, Marc Branchaud wrote: >> On Wed, Apr 25, 2018 at 5:18 PM, Marc Branchaud >> This is a limitation of the current post-checkout hook. $3==0 from the >> hook lets us know this is not a branch switch, but it does not

Re: [RFC PATCH] checkout: Force matching mtime between files

2018-04-28 Thread Duy Nguyen
On Fri, Apr 27, 2018 at 11:08 PM, Elijah Newren wrote: > On Fri, Apr 27, 2018 at 10:03 AM, Duy Nguyen wrote: >> On Wed, Apr 25, 2018 at 5:18 PM, Marc Branchaud wrote: >>> >>> * In a "file checkout" ("git checkout -- path/to/file"), $1

Re: [RFC PATCH] checkout: Force matching mtime between files

2018-04-27 Thread Marc Branchaud
On 2018-04-27 01:03 PM, Duy Nguyen wrote: On Wed, Apr 25, 2018 at 5:18 PM, Marc Branchaud wrote: The best approach to do so is to have those people do the "touch" thing in their own post-checkout hook. People who use Git as the source control system won't have to pay

Re: [RFC PATCH] checkout: Force matching mtime between files

2018-04-27 Thread Elijah Newren
On Fri, Apr 27, 2018 at 10:03 AM, Duy Nguyen wrote: > On Wed, Apr 25, 2018 at 5:18 PM, Marc Branchaud wrote: >> >> * In a "file checkout" ("git checkout -- path/to/file"), $1 and $2 are >> identical so the above loop does nothing. Offhand I'm not even

Re: [RFC PATCH] checkout: Force matching mtime between files

2018-04-27 Thread Ævar Arnfjörð Bjarmason
On Fri, Apr 27, 2018 at 7:18 PM, Michał Górny wrote: > W dniu śro, 25.04.2018 o godzinie 11∶18 -0400, użytkownik Marc Branchaud > napisał: >> On 2018-04-25 04:48 AM, Junio C Hamano wrote: >> > "Robin H. Johnson" writes: >> > >> > > In the thread from 6

Re: [RFC PATCH] checkout: Force matching mtime between files

2018-04-27 Thread Michał Górny
W dniu śro, 25.04.2018 o godzinie 11∶18 -0400, użytkownik Marc Branchaud napisał: > On 2018-04-25 04:48 AM, Junio C Hamano wrote: > > "Robin H. Johnson" writes: > > > > > In the thread from 6 years ago, you asked about tar's behavior for > > > mtimes. 'tar xf' restores mtimes

Re: [RFC PATCH] checkout: Force matching mtime between files

2018-04-27 Thread Duy Nguyen
On Wed, Apr 25, 2018 at 5:18 PM, Marc Branchaud wrote: >> The best approach to do so is to have those people do the "touch" >> thing in their own post-checkout hook. People who use Git as the >> source control system won't have to pay runtime cost of doing the >> touch

Re: [RFC PATCH] checkout: Force matching mtime between files

2018-04-26 Thread Duy Nguyen
On Thu, Apr 26, 2018 at 07:53:58PM +0200, SZEDER Gábor wrote: > BTW, wouldn't running > > git clone --template=/path/to/template/dir/with/hooks/ > > invoke the post-checkout hook in there? > Yes but it's cumbersome, preparing a template just for one extra hook. I never like this template

Re: [RFC PATCH] checkout: Force matching mtime between files

2018-04-26 Thread Duy Nguyen
On Thu, Apr 26, 2018 at 05:48:35PM +, Robin H. Johnson wrote: > On Thu, Apr 26, 2018 at 06:43:56PM +0200, Duy Nguyen wrote: > > On Wed, Apr 25, 2018 at 5:18 PM, Marc Branchaud > > wrote: > > > Are we all that sure that the performance hit is that drastic? After all, >

Re: [RFC PATCH] checkout: Force matching mtime between files

2018-04-26 Thread SZEDER Gábor
> On Wed, Apr 25, 2018 at 10:41:18AM +0200, �var Arnfj�r� Bjarmason wrote: > > 2. Add some config so we can have hook search paths, and ship with a > > default search path for hooks shipped with git. > > I would go for something like this instead of search paths. This > allows you to specify

Re: [RFC PATCH] checkout: Force matching mtime between files

2018-04-26 Thread Robin H. Johnson
On Thu, Apr 26, 2018 at 07:15:40PM +0200, Duy Nguyen wrote: > On Wed, Apr 25, 2018 at 10:41:18AM +0200, Ævar Arnfjörð Bjarmason wrote: > > 2. Add some config so we can have hook search paths, and ship with a > > default search path for hooks shipped with git. > > I would go for something

Re: [RFC PATCH] checkout: Force matching mtime between files

2018-04-26 Thread Robin H. Johnson
On Thu, Apr 26, 2018 at 06:43:56PM +0200, Duy Nguyen wrote: > On Wed, Apr 25, 2018 at 5:18 PM, Marc Branchaud wrote: > > Are we all that sure that the performance hit is that drastic? After all, > > we've just done write_entry(). Calling utime() at that point should just >

Re: [RFC PATCH] checkout: Force matching mtime between files

2018-04-26 Thread Duy Nguyen
On Wed, Apr 25, 2018 at 10:41:18AM +0200, Ævar Arnfjörð Bjarmason wrote: > 2. Add some config so we can have hook search paths, and ship with a > default search path for hooks shipped with git. I would go for something like this instead of search paths. This allows you to specify a path to

Re: [RFC PATCH] checkout: Force matching mtime between files

2018-04-26 Thread Duy Nguyen
On Wed, Apr 25, 2018 at 5:18 PM, Marc Branchaud wrote: > Are we all that sure that the performance hit is that drastic? After all, > we've just done write_entry(). Calling utime() at that point should just > hit the filesystem cache. I have a feeling this has "this is

Re: [RFC PATCH] checkout: Force matching mtime between files

2018-04-26 Thread Michał Górny
W dniu czw, 26.04.2018 o godzinie 10∶25 +0900, użytkownik Junio C Hamano napisał: > Marc Branchaud writes: > > > > But Git is not an archiver (tar), but is a source code control > > > system, so I do not think we should spend any extra cycles to > > > "improve" its

Re: [RFC PATCH] checkout: Force matching mtime between files

2018-04-26 Thread Marc Branchaud
On 2018-04-25 09:25 PM, Junio C Hamano wrote: Marc Branchaud writes: But Git is not an archiver (tar), but is a source code control system, so I do not think we should spend any extra cycles to "improve" its behaviour wrt the relative ordering, at least for the default

Re: [RFC PATCH] checkout: Force matching mtime between files

2018-04-25 Thread Junio C Hamano
Marc Branchaud writes: >> But Git is not an archiver (tar), but is a source code control >> system, so I do not think we should spend any extra cycles to >> "improve" its behaviour wrt the relative ordering, at least for the >> default case. Only those who rely on having

Re: [RFC PATCH] checkout: Force matching mtime between files

2018-04-25 Thread Robin H. Johnson
On Wed, Apr 25, 2018 at 11:18:26AM -0400, Marc Branchaud wrote: > > The best approach to do so is to have those people do the "touch" > > thing in their own post-checkout hook. People who use Git as the > > source control system won't have to pay runtime cost of doing the > > touch thing, and we

Re: [RFC PATCH] checkout: Force matching mtime between files

2018-04-25 Thread Marc Branchaud
On 2018-04-25 04:48 AM, Junio C Hamano wrote: "Robin H. Johnson" writes: In the thread from 6 years ago, you asked about tar's behavior for mtimes. 'tar xf' restores mtimes from the tar archive, so relative ordering after restore would be the same, and would only rebuild

Re: [RFC PATCH] checkout: Force matching mtime between files

2018-04-25 Thread Junio C Hamano
"Robin H. Johnson" writes: > In the thread from 6 years ago, you asked about tar's behavior for > mtimes. 'tar xf' restores mtimes from the tar archive, so relative > ordering after restore would be the same, and would only rebuild if the > original source happened to be

Re: [RFC PATCH] checkout: Force matching mtime between files

2018-04-25 Thread Ævar Arnfjörð Bjarmason
On Mon, Apr 23 2018, Junio C. Hamano wrote: > "Robin H. Johnson" writes: > >> On Fri, Apr 13, 2018 at 07:01:29PM +0200, Michał Górny wrote: >>> Currently git does not control mtimes of files being checked out. This >>> means that the only assumption you could make is that

Re: [RFC PATCH] checkout: Force matching mtime between files

2018-04-25 Thread Robin H. Johnson
On Tue, Apr 24, 2018 at 08:41:07AM +0900, Junio C Hamano wrote: > "Robin H. Johnson" writes: > > > On Fri, Apr 13, 2018 at 07:01:29PM +0200, Michał Górny wrote: > >> Currently git does not control mtimes of files being checked out. This > >> means that the only assumption

Re: [RFC PATCH] checkout: Force matching mtime between files

2018-04-25 Thread Michał Górny
W dniu śro, 25.04.2018 o godzinie 06∶58 +, użytkownik Robin H. Johnson napisał: > On Fri, Apr 13, 2018 at 07:01:29PM +0200, Michał Górny wrote: > > --- a/entry.c > > +++ b/entry.c > > @@ -411,6 +411,7 @@ int checkout_entry(struct cache_entry *ce, > > { > > static struct strbuf path =

Re: [RFC PATCH] checkout: Force matching mtime between files

2018-04-25 Thread Robin H. Johnson
On Fri, Apr 13, 2018 at 07:01:29PM +0200, Michał Górny wrote: > --- a/entry.c > +++ b/entry.c > @@ -411,6 +411,7 @@ int checkout_entry(struct cache_entry *ce, > { > static struct strbuf path = STRBUF_INIT; > struct stat st; > + int ret; > > if (topath) >

Re: [RFC PATCH] checkout: Force matching mtime between files

2018-04-24 Thread Marc Branchaud
On 2018-04-13 01:01 PM, Michał Górny wrote: Currently git does not control mtimes of files being checked out. This means that the only assumption you could make is that all files created or modified within a single checkout action will have mtime between start time and end time of this

Re: [RFC PATCH] checkout: Force matching mtime between files

2018-04-23 Thread Junio C Hamano
"Robin H. Johnson" writes: > On Fri, Apr 13, 2018 at 07:01:29PM +0200, Michał Górny wrote: >> Currently git does not control mtimes of files being checked out. This >> means that the only assumption you could make is that all files created >> or modified within a single

Re: [RFC PATCH] checkout: Force matching mtime between files

2018-04-23 Thread Robin H. Johnson
On Fri, Apr 13, 2018 at 07:01:29PM +0200, Michał Górny wrote: > Currently git does not control mtimes of files being checked out. This > means that the only assumption you could make is that all files created > or modified within a single checkout action will have mtime between > start time and