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 workin
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 regularl
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
>
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.
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 r
On Mon, Mar 11, 2013 at 8:29 PM, Max Horn 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,
On 11.03.2013, at 23:54, Andrew Wong wrote:
> On 3/11/13, Max Horn 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.
>>
>
On 11.03.2013, at 23:54, Andrew Wong wrote:
> On 3/11/13, Max Horn 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.
>>
>
On 3/11/13, Max Horn 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
On 11.03.2013, at 23:10, Andrew Wong wrote:
> On 3/11/13, Max Horn 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
On 11.03.2013, at 22:34, Andrew Wong wrote:
> On 3/11/13, Max Horn wrote:
>> So I tried this:
>>
>> git rebase branches/stable-4.6 # ... which leads to the error
>> git ls-files -m
>>
>> but got nothing. Perhaps you had something else in mind, though, but I am
>> not quite sure what... sorr
On 3/11/13, Max Horn 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 issu
On 3/11/13, Max Horn wrote:
> So I tried this:
>
> git rebase branches/stable-4.6 # ... which leads to the error
> git ls-files -m
>
> but got nothing. Perhaps you had something else in mind, though, but I am
> not quite sure what... sorry for being dense, but if you let me know what
> exactl
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.
All I
On 11.03.2013, at 20:15, Andrew Wong wrote:
> On 3/10/13, Max Horn wrote:
>> I did run
>>
>> touch lib/*.* src/*.* && git update-index --refresh && git diff-files
>>
>> a couple dozen times (the "problematic" files where in src/ and lib), but
>> nothing happened. I just re-checked, and the re
On 3/10/13, Max Horn wrote:
> I did run
>
> touch lib/*.* src/*.* && git update-index --refresh && git diff-files
>
> a couple dozen times (the "problematic" files where in src/ and lib), but
> nothing happened. I just re-checked, and the rebase still fails in the same
> why...
>
> Perhaps I sho
Sorry for taking so long to reply... :-/
On 09.03.2013, at 19:32, Andrew Wong wrote:
> On 03/09/13 06:26, Max Horn wrote:
>> It tends to fail in separate places, but eventually "stabilizes". E.g. I
>> just did a couple test rebases, and it failed twice in commit 14, then the
>> third time in co
On 03/09/13 13:32, Andrew Wong wrote:
> Yea, that's really suspicious. This could mean there's an issue with
> when git is checking the index. Try running these a couple times in a
> clean work tree:
> $ git update-index --refresh
> $ git diff-files
>
> In a clean work tree, these commands
On 03/09/13 06:26, Max Horn wrote:
> It tends to fail in separate places, but eventually "stabilizes". E.g. I just
> did a couple test rebases, and it failed twice in commit 14, then the third
> time in commit 15 (which underlines once more that the failures are
> inappropriate).
>
> The fourth
On 08.03.2013, at 20:20, Andrew Wong wrote:
> On 3/8/13, Max Horn wrote:
>> Same result, it works fine.
>
> Just shooting in the dark here... I wonder if there's some background
> process running in OS X that's messing with the files/directories
> while rebase is working... backup, virus scan,
On 3/8/13, Max Horn wrote:
> Same result, it works fine.
Just shooting in the dark here... I wonder if there's some background
process running in OS X that's messing with the files/directories
while rebase is working... backup, virus scan, etc? Or maybe some
programs that you're using at the same
Am 08.03.2013 um 19:02 schrieb Andrew Wong :
> On 3/8/13, Max Horn wrote:
>> I tried this a dozen times, but 'git apply' failed to fail even once. No
>> surprise there, given that the patch that throws off rebase every time is
>> clean and simple. I am flabbergasted :-(
>
> Hm, what if you add
On 3/8/13, Max Horn wrote:
> I tried this a dozen times, but 'git apply' failed to fail even once. No
> surprise there, given that the patch that throws off rebase every time is
> clean and simple. I am flabbergasted :-(
Hm, what if you add in the "--index" flag? i.e.
git apply --index .git/r
Am 08.03.2013 um 16:32 schrieb Andrew Wong :
> On 3/8/13, Max Horn wrote:
>> All in all, I suspect that Mac OS X and/or the filesystem (HFS+ with
>> journaling, not case sensitive (the default)) might be at fault. Still, this
>> is quite puzzling and annoying, and so I still wonder if anybody h
On 3/8/13, Max Horn wrote:
> All in all, I suspect that Mac OS X and/or the filesystem (HFS+ with
> journaling, not case sensitive (the default)) might be at fault. Still, this
> is quite puzzling and annoying, and so I still wonder if anybody has any
> insights on this.
When "rebase" errors out
A follow up:
I was able to reproduce this behavior on my Mac with multiple git versions down
to 1.6.0.6. On the other hand, I copied the whole work tree to a virtual
machine running Ubuntu, and there the issue did not occur.
All in all, I suspect that Mac OS X and/or the filesystem (HFS+ with
Recently I have observed very strange failures in "git rebase" that cause it to
fail to work automatically in situations where it should trivially be able to
do so.
In case it matter, here's my setup: git 1.8.2.rc2.4.g7799588 (i.e. git.git
master branch) on Mac OS X. The repos clone is on a HFS
27 matches
Mail list logo
