Dear diary, on Thu, Jul 14, 2005 at 05:26:07PM CEST, I got a letter
where Linus Torvalds <[EMAIL PROTECTED]> told me that...
> It's quite possible that some path in cg-update ends up not updating the
> index properly. For example, I notice that the "fast-forward" uses
> "git-checkout-cache -f -a"
On Thu, Jul 14, 2005 at 05:29:09PM -0700, Linus Torvalds wrote:
> On Thu, 14 Jul 2005, Linus Torvalds wrote:
> > I'll look into making diff-cache be more efficient. I normally don't use
> > it myself, so I didn't bother (I use git-diff-files, which is way more
> > efficient, but doesn't show the di
Linus Torvalds <[EMAIL PROTECTED]> writes:
> On Thu, 14 Jul 2005, Linus Torvalds wrote:
>>
>> I'll look into making diff-cache be more efficient. I normally don't use
>> it myself, so I didn't bother (I use git-diff-files, which is way more
>> efficient, but doesn't show the difference against the
On Thu, 14 Jul 2005, Linus Torvalds wrote:
>
> I'll look into making diff-cache be more efficient. I normally don't use
> it myself, so I didn't bother (I use git-diff-files, which is way more
> efficient, but doesn't show the difference against the _tree_, it shows
> the difference against the i
On Thu, 14 Jul 2005, Russell King wrote:
>
> Actually, I should've left the sh -x /usr/bin/cg-diff drivers/serial/8250.c
> running a little longer. It's not the git-update-cache command which
> is taking the time, it's git-diff-cache.
Ok. git-diff-cache actually ends up reading your HEAD tree,
On Thu, 14 Jul 2005, Russell King wrote:
>
> cg-update origin
> and then I edited drivers/serial/8250.c
Hmm..
> it appears that cg-diff does a
>
> git-update-cache --refresh >/dev/null
>
> each time it's run, which is taking the bulk of the time. Also note
> that curiously, it exits
On Thu, Jul 14, 2005 at 10:08:31AM +0100, Catalin Marinas wrote:
> Russell King <[EMAIL PROTECTED]> wrote:
> > it appears that cg-diff does a
> >
> > git-update-cache --refresh >/dev/null
> >
> > each time it's run, which is taking the bulk of the time. Also note
> > that curiously, it exits w
Russell King <[EMAIL PROTECTED]> wrote:
> it appears that cg-diff does a
>
> git-update-cache --refresh >/dev/null
>
> each time it's run, which is taking the bulk of the time. Also note
> that curiously, it exits with status 1.
Does git-ls-files --unmerged show any files?
--
Catalin
-
T
On Wed, Jul 13, 2005 at 06:51:30PM +0200, Matthias Urlichs wrote:
> Hi, Russell King wrote:
>
> > This says it all. 1min 22secs to generate a patch from a locally
> > modified but uncommitted file.
>
> I only get that when the index is out-of-date WRT the file modification
> dates, so cg-diff ha
On Wed, Jul 13, 2005 at 01:28:18PM -0700, Linus Torvalds wrote:
> On Wed, 13 Jul 2005, Russell King wrote:
> > This says it all. 1min 22secs to generate a patch from a locally
> > modified but uncommitted file.
>
> No, there's something else going on.
>
> Most likely that something forced a tota
On Wed, 13 Jul 2005, Russell King wrote:
>
> This says it all. 1min 22secs to generate a patch from a locally
> modified but uncommitted file.
No, there's something else going on.
Most likely that something forced a total index file re-validation, and
the time you see is every single checked o
Hi, Russell King wrote:
> This says it all. 1min 22secs to generate a patch from a locally
> modified but uncommitted file.
I only get that when the index is out-of-date WRT the file modification
dates, so cg-diff has to examine every file.
The good news is that the index is being updated as it
This says it all. 1min 22secs to generate a patch from a locally
modified but uncommitted file.
cp, edit, diff would be several orders of magnitude faster. What's
going on?
$ /usr/bin/time cg-diff drivers/serial/8250.c > o
Command exited with non-zero status 1
14.40user 17.47system 1:22.96elaps
13 matches
Mail list logo
