On 11.03.2013, at 23:10, Andrew Wong wrote:
> On 3/11/13, Max Horn <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
