All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sergio Callegari <sergio.callegari@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: On refreshing the index
Date: Mon, 15 Mar 2010 01:19:01 +0100	[thread overview]
Message-ID: <4B9D7CF5.5010404@gmail.com> (raw)
In-Reply-To: <7vmxyb3la7.fsf@alter.siamese.dyndns.org>

Junio C Hamano wrote:
> Sergio Callegari <sergio.callegari@gmail.com> writes:
>
>   
>> If I run git status, git runs filters on a couple of opendocument files for
>> which a filter is defined
>>
>> GIT_TRACE=1 git status
>> trace: built-in: git 'status'
>> trace: run_command: 'rezip -p ODF_UNCOMPRESS2'
>> trace: exec: 'sh' '-c' 'rezip -p ODF_UNCOMPRESS2' 'rezip -p ODF_UNCOMPRESS2'
>> trace: run_command: 'rezip -p ODF_UNCOMPRESS2'
>> trace: exec: 'sh' '-c' 'rezip -p ODF_UNCOMPRESS2' 'rezip -p ODF_UNCOMPRESS2'
>> # On branch M05
>> # Untracked files:
>> #   (use "git add <file>..." to include in what will be committed)
>> #
>> #       WIP/
>> #       program.txt
>> #       program.txt~
>> nothing added to commit but untracked files present (use "git add" to track)
>>     
>
> What does "git diff-files" and/or "git diff-index HEAD" say at this point?
> If they do not say there are no difference, that means that the file on
> the filesystem and the blob registered in the index are different, even
> though after transmogrified with rezip (whatever it does) these two
> different blobs may look the same.
>   
Neither git diff-files" and/or "git diff-index HEAD say nothing at this 
point...

> I think the difference between "may look the same" and "identical" is what
> you are seeing.  Try "git add" on those paths and see what happens.
>   
Is there any way I can find out which file is the guilty one since git 
diff-files says nothing? E.g. a trace telling me on what is the filter 
being called?

BTW... some notes that may be useful...

1) rezip is a mere recompressor.  It takes a zip file and re-creates it 
at zero compression, so that the git delta logic can do a good job on it 
on repacking.  I've found this useful on zip files, openoffice files, 
jar files, etc.

2) if I clone outside git, git update-index --refresh is always ok at 
making git status fast (i.e. not running expensive filters).

3) The problem always happens when I switch branches, right after the 
switch.

Sergio

      reply	other threads:[~2010-03-15  0:19 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-11 18:19 On refreshing the index Sergio Callegari
2010-03-13 22:32 ` Junio C Hamano
2010-03-15  0:19   ` Sergio Callegari [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4B9D7CF5.5010404@gmail.com \
    --to=sergio.callegari@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.