git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Andrew Wong <andrew.kw.w@gmail.com>
Date
Mar 11, 2013, 19:15 UTC
Message-ID
<CADgNjanQxMFrQG=7SqgAXv5PW8OEfG+1kZt_Mrq27OcP1uyGtA@mail.gmail.com>
In-Reply-To
<C79E1B20-2C42-49FF-A964-285A7049FDED@quendi.de>
On 3/10/13, Max Horn <max@quendi.de> wrote:
Show 13 quoted lines
> 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".

Previous: Max HornNext: Max Horn
Message 12 of 27 in “rebase: strange failures to apply patc 3-way”
  1. Max HornMar 7, 2013
  2. Max HornMar 8, 2013
  3. Andrew WongMar 8, 2013
  4. Max HornMar 8, 2013
  5. Andrew WongMar 8, 2013
  6. Max HornMar 8, 2013
  7. Andrew WongMar 8, 2013
  8. Max HornMar 9, 2013
  9. Andrew WongMar 9, 2013
  10. Andrew WongMar 9, 2013
  11. Max HornMar 10, 2013
  12. Andrew WongMar 11, 2013
  13. Max HornMar 11, 2013
  14. Andrew WongMar 11, 2013
  15. Max HornMar 11, 2013
  16. Max HornMar 11, 2013
  17. Andrew WongMar 11, 2013
  18. Max HornMar 11, 2013
  19. Andrew WongMar 11, 2013
  20. Max HornMar 12, 2013
  21. Max HornMar 12, 2013
  22. John SzakmeisterMar 12, 2013
  23. Andrew WongMar 12, 2013
  24. Jeff KingMar 12, 2013
  25. Andrew WongMar 12, 2013
  26. Jeff KingMar 12, 2013
  27. Heiko VoigtMar 12, 2013

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.