Hi Junio,
On Fri, 3 Feb 2017, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > I could imagine that there is a third option we should consider, too: only
> > lstat() and update the paths that match the pathspec(s) provided on the
> > command line (this is the semantic meaning of the -
Johannes Schindelin writes:
>> Besides, leaving the main index not refreshed would mean the user
>> has to pay the refreshing cost when s/he runs other commands "git
>> diff", "git status", etc. after "git commit" for the first time;
>> so...
>
> I am not sure... when you run `git diff` and `git
Hi Junio,
On Fri, 3 Feb 2017, Junio C Hamano wrote:
> Aside from whitespace breakage, I think we should never skip the
> refreshing of the real index that is left after "git commit"
> finishes.
>
> Between these two calls to refresh_cache(), the one that writes out
> a temporary index that conta
Aside from whitespace breakage, I think we should never skip the
refreshing of the real index that is left after "git commit"
finishes.
Between these two calls to refresh_cache(), the one that writes out
a temporary index that contains the contents of HEAD plus the
contents of the working tree for
"Gumbel, Matthew K" writes:
> When making a --only commit, original behavior was to do a full cache
> update for the purposes of giving the pre-commit hook an up-to-date set
> of stat data. That would result in long runtime for git-commit in a big
> repo on NFS (>60s for a 54k-file repo).
>
> W
When making a --only commit, original behavior was to do a full cache
update for the purposes of giving the pre-commit hook an up-to-date set
of stat data. That would result in long runtime for git-commit in a big
repo on NFS (>60s for a 54k-file repo).
With this change, when doing a --only comm
6 matches
Mail list logo
