Re: Quick question: how to generate a patch?

From: Linus Torvalds <torvalds@osdl.org>
Date: Feb 27, 2006, 17:19 UTC
Message-ID: <Pine.LNX.4.64.0602270909500.22647@g5.osdl.org>
In-Reply-To: <6d6a94c50602270902k2c06aaffw7e70268b0753ef64@mail.gmail.com>

On Tue, 28 Feb 2006, Aubrey wrote:

Show 6 quoted lines

> 
> =================================================================
> aubrey@linux:/checkout/uboot/patch/work/drivers> git diff
> ----snip----
> diff --git a/drivers/sk98lin/skxmac2.c b/drivers/sk98lin/skxmac2.c
> diff --git a/drivers/sk98lin/u-boot_compat.h b/drivers/sk98lin/u-boot_compat.h

Ok, this is _definitely_ your index being out of touch with your file contents.

Run "git-update-index --refresh" and it should be ok.

Now the question is why the index got out-of-kilter with the file contents in the first place. I used to have all these debug aids to show why git thought a file had changed, but we've not had any bugs here for a long long time, so..

The final checkout of the "git clone" should have made sure that the index is up-to-date.

Show 15 quoted lines

> >         git clone remote-repo localdir
> >         cd localdir
> >         vi somefile
> >         git diff
>
> Yes, exactly right.
> 
> > then you did everything right, and if it gives any diff other than your
> > changes to "somefile", something is buggy. Need more info.
> >
> > Does "git diff" and "git diff HEAD" give different results, btw?
> 
> Yes. the two commands give the same results.
> 
> I'm using git-1.2.3

What OS/filesystem?

The way the index keeps track of files that haven't changed is by checking the size, the mtime and the ctime of the inode. It also checks the user/gid and inode number. If you use a filesystem where those might change (networked?), that might cause this..

		Linus