On 11.03.2013, at 23:10, Andrew Wong wrote: > On 3/11/13, Max Horn <max@xxxxxxxxx> 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? [core] 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. Cheers, Max-- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html