Robin Rosenberg writes:
> - Ursprungligt meddelande -
>
>> That configurability is a slipperly slope to drag us into giving
>> users
>> more complexity that does not help them very much, I suspect.
>>
>> Earlier somebody mentioned "size and mtime is often enough", so I
>> think a single
- Ursprungligt meddelande -
> That configurability is a slipperly slope to drag us into giving
> users
> more complexity that does not help them very much, I suspect.
>
> Earlier somebody mentioned "size and mtime is often enough", so I
> think a single option core.looseStatInfo (substi
Junio C Hamano wrote:
> Robin Rosenberg writes:
> That configurability is a slipperly slope to drag us into giving users
> more complexity that does not help them very much, I suspect.
>
> Earlier somebody mentioned "size and mtime is often enough", so I
> think a single option core.looseStatInf
Robin Rosenberg writes:
>> I'd say a simplistic "ignore if zero is stored" or even "ignore this
>> as one of the systems that shares this file writes crap in it" may
>> be sufficient, and if this is a jGit specific issue, it might even
>> make sense to introduce a single configuration variable wi
- Ursprungligt meddelande -
> Robin Rosenberg writes:
>
> > Semantically they're somewhat different. My flags are for ignoring
> > a value when it's not used as indicated by the value zero, while
> > trustctime is for ignoring untrustworthy, non-zero, values.
>
> Yeah, I realized that
Am 1/15/2013 1:11, schrieb Junio C Hamano:
> I'd say a simplistic "ignore if zero is stored" or even "ignore this
> as one of the systems that shares this file writes crap in it" may
> be sufficient, and if this is a jGit specific issue, it might even
> make sense to introduce a single configuratio
> Is this "the user edits in eclipse and then runs 'git status' from
> the
> terminal" problem?
Yes. Of course not just status, but any command that validates
the index. On Unix this is usually bearable, though slow, but on
Windows I often see git status take minutes (yes large files...).
-- rob
Robin Rosenberg writes:
> Semantically they're somewhat different. My flags are for ignoring
> a value when it's not used as indicated by the value zero, while
> trustctime is for ignoring untrustworthy, non-zero, values.
Yeah, I realized that after writing that message.
> Another thing that I
- Ursprungligt meddelande -
> Robin Rosenberg writes:
>
> > diff --git a/read-cache.c b/read-cache.c
> > index fda78bc..f7fe15d 100644
> > --- a/read-cache.c
> > +++ b/read-cache.c
> > @@ -197,8 +197,9 @@ static int ce_match_stat_basic(struct
> > cache_entry *ce, struct stat *st)
> >
Robin Rosenberg writes:
> @@ -566,6 +566,31 @@ static int git_default_core_config(const char *var,
> const char *value)
> trust_ctime = git_config_bool(var, value);
> return 0;
> }
> + if (!strcmp(var, "core.ignorezerostat")) {
> + char *copy, *t
Robin Rosenberg writes:
> diff --git a/read-cache.c b/read-cache.c
> index fda78bc..f7fe15d 100644
> --- a/read-cache.c
> +++ b/read-cache.c
> @@ -197,8 +197,9 @@ static int ce_match_stat_basic(struct cache_entry *ce,
> struct stat *st)
> }
> if (ce->ce_mtime.sec != (unsigned int)st-
Specifically the fields uid, gid, ctime, ino and dev are set to zero
by JGit. Any stat checking by git will then need to check content,
which may be very slow, particularly on Windows. Since mtime and size
is typically enough we should allow the user to tell git to avoid
checking these fields if th
12 matches
Mail list logo
