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
On 3/10/13, Max Horn m...@quendi.de 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
On 11.03.2013, at 20:15, Andrew Wong wrote:
On 3/10/13, Max Horn m...@quendi.de 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
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 3/11/13, Max Horn m...@quendi.de 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
On 3/11/13, Max Horn m...@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
On 11.03.2013, at 22:34, Andrew Wong wrote:
On 3/11/13, Max Horn m...@quendi.de 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...
On 11.03.2013, at 23:10, Andrew Wong wrote:
On 3/11/13, Max Horn m...@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,
On 3/11/13, Max Horn m...@quendi.de 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
On 11.03.2013, at 23:54, Andrew Wong wrote:
On 3/11/13, Max Horn m...@quendi.de 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 m...@quendi.de 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 Mon, Mar 11, 2013 at 8:29 PM, Max Horn m...@quendi.de 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
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
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
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 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
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 commit 15
On 08.03.2013, at 20:20, Andrew Wong wrote:
On 3/8/13, Max Horn m...@quendi.de 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,
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 should
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
On 3/8/13, Max Horn m...@quendi.de 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
Am 08.03.2013 um 16:32 schrieb Andrew Wong andrew.k...@gmail.com:
On 3/8/13, Max Horn m...@quendi.de 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
On 3/8/13, Max Horn m...@quendi.de 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
Am 08.03.2013 um 19:02 schrieb Andrew Wong andrew.k...@gmail.com:
On 3/8/13, Max Horn m...@quendi.de 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
On 3/8/13, Max Horn m...@quendi.de 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
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+
26 matches
Mail list logo
