rebase: strange failures to apply patc 3-way

[Max Horn]

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

> On 3/11/13, Max Horn <[hidden email]> wrote:
>> 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.
>
> Would you be able to turn off Time Machine completely and do a few
> tests? If it does works, then it becomes a matter of fixing Time
> Machine...
>

sudo launchctl unload /System/Library/LaunchDaemons/com.apple.revisiond.plist

-> this exits revisiond, and prevents launchd from respawning it. After that, the problem is gone, on several attempts. And once I reactivate revisions, the problem reoccurs.

So it seems pretty clear what the cause of this is. Now I still need to figure out why it affects that particular repository and not others. But at this point I guess it is safe to say that Apple's auto-crap-magic revisiond is the root of the problem, and git is purely a victim. So I'll stop spamming this list with this issue for now, and see if I can figure out a fix that is less invasive than turning off revisiond completely (which some application rely on, so disabling it may break them badly).

Andrew, thank you very much for your persistent guidance and help. I definitely owe you a beverage-of-your-choice ;-).

Cheers,
Max--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[John Szakmeister]

On Mon, Mar 11, 2013 at 8:29 PM, Max Horn <[hidden email]> wrote:
[snip]
>
> sudo launchctl unload /System/Library/LaunchDaemons/com.apple.revisiond.plist
>
> -> this exits revisiond, and prevents launchd from respawning it. After that, the problem is gone, on several attempts. And once I reactivate revisions, the problem reoccurs.
>
> So it seems pretty clear what the cause of this is. Now I still need to figure out why it affects that particular repository and not others. But at this point I guess it is safe to say that Apple's auto-crap-magic revisiond is the root of the problem, and git is purely a victim. So I'll stop spamming this list with this issue for now, and see if I can figure out a fix that is less invasive than turning off revisiond completely (which some application rely on, so disabling it may break them badly).

I just wanted to say thank you for spamming the list with this.  I've
not upgraded to a new Mac OS X yet, but now I know I need to watch out
for this issue.  I'm glad you were able to get to the bottom of it,
and I'd love to hear if you find a reasonable solution.

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

[Andrew Wong-2]

On 03/11/13 20:29, Max Horn wrote:
> sudo launchctl unload /System/Library/LaunchDaemons/com.apple.revisiond.plist
>
> -> this exits revisiond, and prevents launchd from respawning it. After that, the problem is gone, on several attempts. And once I reactivate revisions, the problem reoccurs.
>
> So it seems pretty clear what the cause of this is. Now I still need to figure out why it affects that particular repository and not others. But at this point I guess it is safe to say that Apple's auto-crap-magic revisiond is the root of the problem, and git is purely a victim. So I'll stop spamming this list with this issue for now, and see if I can figure out a fix that is less invasive than turning off revisiond completely (which some application rely on, so disabling it may break them badly).
>
> Andrew, thank you very much for your persistent guidance and help. I definitely owe you a beverage-of-your-choice ;-).
Awesome! I was starting to worry that we'd never figure out what the
issue is. Good thing you know your way around OS X and its debugging
tools. :)

Maybe drop an email if you figure out what's causing revisiond to be so
persistent about those specific files. Might help any who run into
similar issues in the future.

Cheers!
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Jeff King]

On Tue, Mar 12, 2013 at 01:29:45AM +0100, Max Horn wrote:

> So it seems pretty clear what the cause of this is. Now I still need
> to figure out why it affects that particular repository and not
> others. But at this point I guess it is safe to say that Apple's
> auto-crap-magic revisiond is the root of the problem, and git is
> purely a victim. So I'll stop spamming this list with this issue for
> now, and see if I can figure out a fix that is less invasive than
> turning off revisiond completely (which some application rely on, so
> disabling it may break them badly).

From "git help config":

  core.trustctime
    If false, the ctime differences between the index and the working
    tree are ignored; useful when the inode change time is regularly
    modified by something outside Git (file system crawlers and some
    backup systems). See git-update- index(1). True by default.

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

[Andrew Wong-2]

On 03/11/13 21:01, Jeff King wrote:
> From "git help config":
>
>   core.trustctime
>     If false, the ctime differences between the index and the working
>     tree are ignored; useful when the inode change time is regularly
>     modified by something outside Git (file system crawlers and some
>     backup systems). See git-update- index(1). True by default.
In an earlier email, Max did mention setting the config does workaround
the issue. But it's still strange that it only happens to a few specific
files in this particular repo. The issue never popped up in other repos
that he has, which I assume has all been excluded from Time Machine...
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Jeff King]

On Mon, Mar 11, 2013 at 09:03:42PM -0400, Andrew Wong wrote:

> On 03/11/13 21:01, Jeff King wrote:
> > From "git help config":
> >
> >   core.trustctime
> >     If false, the ctime differences between the index and the working
> >     tree are ignored; useful when the inode change time is regularly
> >     modified by something outside Git (file system crawlers and some
> >     backup systems). See git-update- index(1). True by default.
>
> In an earlier email, Max did mention setting the config does workaround
> the issue. But it's still strange that it only happens to a few specific
> files in this particular repo. The issue never popped up in other repos
> that he has, which I assume has all been excluded from Time Machine...

Ah, sorry, I missed the earlier reference to it. trustctime is the only
sensible thing to do from the git side. I think figuring out the rest is
deep Apple magic that I'm not qualified to comment on.

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

[Heiko Voigt-3]

On Mon, Mar 11, 2013 at 09:10:04PM -0400, Jeff King wrote:

> On Mon, Mar 11, 2013 at 09:03:42PM -0400, Andrew Wong wrote:
>
> > On 03/11/13 21:01, Jeff King wrote:
> > > From "git help config":
> > >
> > >   core.trustctime
> > >     If false, the ctime differences between the index and the working
> > >     tree are ignored; useful when the inode change time is regularly
> > >     modified by something outside Git (file system crawlers and some
> > >     backup systems). See git-update- index(1). True by default.
> >
> > In an earlier email, Max did mention setting the config does workaround
> > the issue. But it's still strange that it only happens to a few specific
> > files in this particular repo. The issue never popped up in other repos
> > that he has, which I assume has all been excluded from Time Machine...
>
> Ah, sorry, I missed the earlier reference to it. trustctime is the only
> sensible thing to do from the git side. I think figuring out the rest is
> deep Apple magic that I'm not qualified to comment on.

From what I read isn't the ctime the only thing that changes? I read
that you tried this option and the issues disappeared? Maybe the
resolution (or part of it) is to change the default of core.trustctime
to false on osx?

Cheers Heiko
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html