On 11.03.2013, at 23:10, Andrew Wong wrote:

> On 3/11/13, Max Horn <m...@quendi.de> wrote:
>> PS: Just as a side note, I should mention that I have done tons of rebases
>> on various repositories on this very machine: same hard drive, same file
>> system; the git version of course has changed over time, but as I already
>> described, I can reproduce the same issue with older git versions.
> What if you do a "git clone" from this repo to an entirely new repo? I
> wonder if the rebase issue still happens in the new repo...

The problem seems to be non-existent in a clone. 

> Could you also post the .git/config file from the repo?

        repositoryformatversion = 0
        filemode = true
        bare = false
        logallrefupdates = true
        ignorecase = true
        precomposeunicode = false

Other than that, it just contains some a [remote] section and several [branch] 
sections. None of these contains any fancy (i.e. the branch sections just say 
"remote = origin" and give the name of the remote branch).

Looking at the git config man page to check what each of my config settings 
does, I discovered "trustctime". And adding
        trustctime = false
to .git/config made the rebase work, every single time. Huh. 

Adding this to the fact that a clone works fine, I wonder if  something *is* 
touching my files, but just in that directory. But what could it be? One 
nagging suspicion is the "file versioning" feature Apple introduced as part of 
Time Machine in OS X 10.7; it's kind of a "version control system for n00bs" 
for arbitrary documents. It has caused me some pain in the past.

But I just re-checked, and problematic repos is explicitly on the Time Machine 
exclusion list. I also used the "tmutil isexcluded FILES" to verify that the 
problematic files are really on the TM exclusion list. Finally, I moved the one 
of the repos subdirectory containing most of the problematic files, and then 
run "git checkout". In other instances, this sufficed to "disassociate" a file 
from an unwanted TM version history. But doing that had no effect here, i.e. 
also with the freshly regenerated files, the problems appear.

> If supported, git could actually make use of threading when doing
> "stat"... it should be disabled by default though, but you could try
> disabling it with this config:
>    git config core.preloadindex false
> But I don't know why that'd only affect this one repo and not the
> others though...
This setting doesn't seem to have any effect on the issue at hand.

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to