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 source and target fi
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 also
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 (\n or NUL?) or escaping. This mention
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 direction. I could prod
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 the timestamp of wh
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 repository
> > which combi
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 clean. I have resear
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 really
>> tell you the affected paths. If it someh
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 and $2 are
>>> identical so the above loop does nothing. Off
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 runtime cost of doing the
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 sure how a
>> hook might get the right files
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 years ago, you asked about tar's behavior fo
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 from the tar archive
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 thing, and we do not have t
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 thin
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,
> > > we've just done wri
> 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
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 like
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
> > hit the filesystem c
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 an
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 linux" assumption. Anybody
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 behaviour wrt the relative orde
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 case. Only those who re
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 build artifact *and*
>>
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 d
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 if the
original source
"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 dirty.
>
> This behavior
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 all files created
>>>
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 = STRBU
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 you could make is that
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)
> retur
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 checkout.
"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 checkout action will have
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 en
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 checkout. The relations between mtimes
of different fi
35 matches
Mail list logo
