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

From: Max Horn <max@quendi.de>
Date: Mar 11, 2013, 22:20 UTC
Message-ID: <733410BB-7075-4799-B129-EAD5E64652B3@quendi.de>
In-Reply-To: <CADgNjanBm5bj7_jY5WrUXUENr7r6zMxve822OYKcyBpWGZv-SA@mail.gmail.com>

On 11.03.2013, at 22:34, Andrew Wong wrote:

Show 16 quoted lines

> On 3/11/13, Max Horn <max@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
>> exactly you meant, I'll be happy to try that. As for the stat command:
> 
> I'm still digesting the information form the email. Just want to
> quickly mention that the "ls-files" command should be:
>    $ git ls-files --debug file1 file2
> 
> You should always get output. It prints out stat-like information for
> files in the index.

Aha, I see. I inserted that into git-am, once right before git-merge-recursive and once right after it (just before a call to rerere).

This is what I got;

Applying: COMMIT X
error: BAD-FILE: does not match index
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
GOOD-FILE
  ctime: 1362921639:0
  mtime: 1362921639:0
  dev: 234881028	ino: 18665879
  uid: 502	gid: 20
  size: 25429	flags: 0
BAD-FILE
  ctime: 1363040264:0
  mtime: 1363040264:0
  dev: 234881028	ino: 19170773
  uid: 502	gid: 20
  size: 52906	flags: 0
error: Your local changes to the following files would be overwritten by merge:
	BAD-FILE
Please, commit your changes or stash them before you can merge.
Aborting
GOOD-FILE
  ctime: 1362921639:0
  mtime: 1362921639:0
  dev: 234881028	ino: 18665879
  uid: 502	gid: 20
  size: 25429	flags: 0
BAD-FILE
  ctime: 1363040264:0
  mtime: 1363040264:0
  dev: 234881028	ino: 19170773
  uid: 502	gid: 20
  size: 52906	flags: 0
Failed to merge in the changes.
Patch failed at 0015 COMMIT X
...

So the ctime/mtine for the BAD-FILE do not differ. After this, I also run "ls-files" on the command line, and got:

GOOD-FILE gd
  ctime: 1362921639:0
  mtime: 1362921639:0
  dev: 234881028	ino: 18665879
  uid: 502	gid: 20
  size: 25429	flags: 0
BAD-FILE
  ctime: 1363040266:0
  mtime: 1363040264:0
  dev: 234881028	ino: 19170773
  uid: 502	gid: 20
  size: 52906	flags: 0

So now the ctime of the bad file is more recent than the mtime.

Max