On 3/10/13, Max Horn <max@xxxxxxxxx> 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 should add some printfs into the git source to figure out what
> exactly it thinks is not right about those files... i.e. how does it come to
> the conclusion that I have local changes, exactly. I don't know how Git does
> that -- does it take the mtime from (l)stat into account? Perhaps problems
> with my machine's clock could be responsible?
Instead of using "touch", maybe it'd be better if you run "ls-files"
and "stat" at the point where rebase failed. You should run the
command as soon as rebase failed. Don't try to run any git commands,
as they might change the index state.
And yes, git does make use of mtime and ctime from lstat to some
degree when detecting file changes. Inserting printf's to print the
timestamp might help, but the output might be too overwhelming to make
out useful information, especially during a rebase.
BTW, it looks like "stat" command on OS X only prints out timestamps
in seconds, and doesn't show you the nanoseconds part, which may be
significant in your situation. Instead of using the "stat" command,
try using this python command to print out the nanoseconds parts:
python -c "import sys;import os;s=os.stat(sys.argv[1]);print('%d, %f,
%f' % (s.st_size, s.st_ctime, s.st_mtime))" file1
Perhaps you could hack git-am.sh a bit to get more debugging info too.
Hm, maybe a good place to start is un-silencing the output of "git
apply". Inside "git-am.sh", you should see a line like:
git apply $squelch
Remove the $squelch, and see what output it generates.
Also, since you're getting the 3-way merge, you could also insert the
"ls-files" and "stat" right after "git-merge-recursive", but before
"die".
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html