Re: rebase: strange failures to apply patc 3-way

From: Max Horn <max@quendi.de>
Date: Mar 11, 2013, 22:36 UTC
Message-ID: <ED1442D4-C011-49F3-928C-0BE0280F7D42@quendi.de>
In-Reply-To: <CADgNja=QJpe2nmqKn9rR1os=zjjqK+dWA+ZLaJA4pgLG8tVgzg@mail.gmail.com>

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

Show 8 quoted lines

> On 3/11/13, Max Horn <max@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?

[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.

Show 9 quoted lines

> 
> 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