Quick question: how to generate a patch?

Quick question: how to generate a patch?

[Aubrey]

Hi all,

I'm a newbie of git. I have a question about how to generate a patch by git.
I want to make a patch againt git repository HEAD. So in my local
tree, I do the command:

git diff -p > my.patch

The file my.patch is generated. But the unchanged files information is
also included in the patch file. It should be quiet.
Was I wrong to use git by this way?

Thanks for your hints.

Regards,
-Aubrey

Re: Quick question: how to generate a patch?

[Andreas Ericsson]

Aubrey wrote:
> Hi all,
> 
> I'm a newbie of git. I have a question about how to generate a patch by git.
> I want to make a patch againt git repository HEAD. So in my local
> tree, I do the command:
> 
> git diff -p > my.patch
> 
> The file my.patch is generated. But the unchanged files information is
> also included in the patch file. It should be quiet.
> Was I wrong to use git by this way?
> 
> Thanks for your hints.
> 

The current best practice involves these steps:
1. Create a topic branch (git checkout -b feature-name)
2. Apply your changes and commit them, preferrably in small and isolated 
steps, making sure it compiles after each change.
3. Run "git format-patch origin".

This will result in one or more commit-patches, which contains your 
author info, the commit-messages you wrote, the commit-time and all 
other such info and ofcourse the diff in unified git format. You can 
send those patches on using "git send-email" or apply them using "git am 
-k 00*.txt".

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: Quick question: how to generate a patch?

[Linus Torvalds]

On Mon, 27 Feb 2006, Aubrey wrote:
> 
> I'm a newbie of git. I have a question about how to generate a patch by git.
> I want to make a patch againt git repository HEAD. So in my local
> tree, I do the command:
> 
> git diff -p > my.patch

You don't need the "-p" - it's the default for "git diff".

> The file my.patch is generated. But the unchanged files information is
> also included in the patch file. It should be quiet.

It sounds like your index is not synchronized with your file contents. 
Have you done "touch" on files? Or edited them, and then edited them back?

If so, "git-update-index --refresh" will re-synchronize your index with 
whatever file contents you have.

			Linus

Re: Quick question: how to generate a patch?

[Aubrey]

> > The file my.patch is generated. But the unchanged files information is
> > also included in the patch file. It should be quiet.
>
> It sounds like your index is not synchronized with your file contents.
> Have you done "touch" on files? Or edited them, and then edited them back?
>
> If so, "git-update-index --refresh" will re-synchronize your index with
> whatever file contents you have.
>
No, what I did was just "git clone" one repository to my local directory.
And entered the local directory to modify one file I wanted.
Then I run "git diff > my.patch". The "my.patch" was supposed to
contain one file diff information. But it contained the all the files,
including which were not changed.

Thanks to reply. I''ll try to Andreas's suggestion.

Regards,
-Aubrey

Re: Quick question: how to generate a patch?

[Linus Torvalds]

On Tue, 28 Feb 2006, Aubrey wrote:
>
> No, what I did was just "git clone" one repository to my local directory.
> And entered the local directory to modify one file I wanted.
> Then I run "git diff > my.patch". The "my.patch" was supposed to
> contain one file diff information. But it contained the all the files,
> including which were not changed.

It really should "just have worked". Can you show what the diff actually 
looked like, and your exact command history?

If it was something like

	git clone remote-repo localdir
	cd localdir
	vi somefile
	git diff

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?

		Linus

Re: Quick question: how to generate a patch?

[Aubrey]

> It really should "just have worked". Can you show what the diff actually
> looked like, and your exact command history?

=================================================================
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
diff --git a/drivers/sk98lin/uboot_drv.c b/drivers/sk98lin/uboot_drv.c
diff --git a/drivers/sk98lin/uboot_skb.c b/drivers/sk98lin/uboot_skb.c
diff --git a/drivers/sl811.h b/drivers/sl811.h
diff --git a/drivers/sl811_usb.c b/drivers/sl811_usb.c
diff --git a/drivers/sm501.c b/drivers/sm501.c
diff --git a/drivers/smc91111.c b/drivers/smc91111.c
diff --git a/drivers/smc91111.h b/drivers/smc91111.h
index cf08582..e5742ba 100644
--- a/drivers/smc91111.h
+++ b/drivers/smc91111.h
@@ -185,6 +185,8 @@ typedef unsigned long int           dword;

 #ifdef CONFIG_ADNPESC1
 #define        SMC_inw(r)      (*((volatile word
*)(SMC_BASE_ADDRESS+((r)<<1))))
+#elif CONFIG_BLACKFIN
+#define SMC_inw(r)      ({ word __v = (*((volatile word
*)(SMC_BASE_ADDRESS+(r)))); __builtin_bfin_ssync(); __v;})
 #else
 #define        SMC_inw(r)      (*((volatile word *)(SMC_BASE_ADDRESS+(r))))
 #endif
@@ -192,6 +194,8 @@ typedef unsigned long int           dword;

 #ifdef CONFIG_ADNPESC1
 #define        SMC_outw(d,r)   (*((volatile word
*)(SMC_BASE_ADDRESS+((r)<<1))) = d)
+#elif CONFIG_BLACKFIN
+#define SMC_outw(d,r)   {(*((volatile word *)(SMC_BASE_ADDRESS+(r)))
= d);__builtin_bfin_ssync();}
 #else
 #define        SMC_outw(d,r)   (*((volatile word *)(SMC_BASE_ADDRESS+(r))) = d)
 #endif
@@ -232,6 +236,8 @@ typedef unsigned long int           dword;

 #ifdef CONFIG_XSENGINE
 #define        SMC_inl(r)      (*((volatile dword *)(SMC_BASE_ADDRESS+(r<<1))))
+#elif CONFIG_BLACKFIN
+#define SMC_inl(r)      ({ dword __v = (*((volatile dword
*)(SMC_BASE_ADDRESS+(r))));__builtin_bfin_ssync(); __v;})
 #else
 #define        SMC_inl(r)      (*((volatile dword *)(SMC_BASE_ADDRESS+(r))))
 #endif
@@ -247,6 +253,8 @@ typedef unsigned long int           dword;

 #ifdef CONFIG_XSENGINE
 #define        SMC_outl(d,r)   (*((volatile dword
*)(SMC_BASE_ADDRESS+(r<<1))) = d)
+#elif CONFIG_BLACKFIN
+#define SMC_outl(d,r)   {(*((volatile dword *)(SMC_BASE_ADDRESS+(r)))
= d);__builtin_bfin_ssync();}
 #else
 #define        SMC_outl(d,r)   (*((volatile dword
*)(SMC_BASE_ADDRESS+(r))) = d)
 #endif
diff --git a/drivers/smiLynxEM.c b/drivers/smiLynxEM.c
diff --git a/drivers/status_led.c b/drivers/status_led.c
diff --git a/drivers/sym53c8xx.c b/drivers/sym53c8xx.c
diff --git a/drivers/ti_pci1410a.c b/drivers/ti_pci1410a.c
diff --git a/drivers/tigon3.c b/drivers/tigon3.c
diff --git a/drivers/tigon3.h b/drivers/tigon3.h
diff --git a/drivers/tsec.c b/drivers/tsec.c
diff --git a/drivers/tsec.h b/drivers/tsec.h
----snip----
=================================================================
>
> If it was something like
>
>         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

Regards,
-Aubrey

Re: Quick question: how to generate a patch?

[Andreas Ericsson]

Aubrey wrote:
>>It really should "just have worked". Can you show what the diff actually
>>looked like, and your exact command history?
> 
> 
> 
>>If it was something like
>>
>>        git clone remote-repo localdir
>>        cd localdir
>>        vi somefile
>>        git diff
>>
> 
> Yes, exactly right.
> 

Did you by any chance do chmod -R, chown -R or start an ntp daemon 
somewhere in between there (don't know if clock skews will be detected 
by git, but...)?

> 
>>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.
> 

Decidedly odd. What happens when you do "git update-index --refresh" and 
then re-run the "git diff > my.patch" thing?

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: Quick question: how to generate a patch?

[Aubrey]

> Did you by any chance do chmod -R, chown -R or start an ntp daemon
> somewhere in between there (don't know if clock skews will be detected
> by git, but...)?

No, I did nothing between "git clone" and "git diff" except changing one file.
>
>
> Decidedly odd. What happens when you do "git update-index --refresh" and
> then re-run the "git diff > my.patch" thing?
>
Yes, "git update-index --refresh" works. After this command, I got what I want.
It's the diff in unified git format.

Regards,
-Aubrey

Re: Quick question: how to generate a patch?

[Linus Torvalds]

On Mon, 27 Feb 2006, Andreas Ericsson wrote:
> 
> Did you by any chance do chmod -R, chown -R or start an ntp daemon somewhere
> in between there (don't know if clock skews will be detected by git, but...)?

off on this tangent: git shouldn't care about clock skew, because git 
never cares about the current time. The only thing that matters is that 
"stat()" returns the same time when called sequentially.

Now, if you have a distributed filesystem, and the _filesystem_ has some 
strange clock-skew problem, that would definitely screw up git.

That sounds insane, but a trivial case of it might be a networked 
filesystem where the mtime/ctime for a file create is filled in by the 
client first, but then the server will do the "final version" when it 
actually writes the file.

We used to have some bugs in our NFS client that did things like that: the 
"mtime" of a file had this confusing duality between "client time" and 
"server time", and it depended on whether the client had done a "getattr" 
to the server which one you saw.

I could well imagine that we still have some bug like that (ctime in 
particular is much less used than mtime, and thus more likely to have not 
been noticed). And it could be much worse on some less-commonly-used and 
less-unixy networked filesystem like smb, which is why I was wondering 
what OS version and filesystem Aubrey might be using.

		Linus

Re: Quick question: how to generate a patch?

[Aubrey]

On 2/28/06, Linus Torvalds <torvalds@osdl.org> wrote:
> I could well imagine that we still have some bug like that (ctime in
> particular is much less used than mtime, and thus more likely to have not
> been noticed). And it could be much worse on some less-commonly-used and
> less-unixy networked filesystem like smb, which is why I was wondering
> what OS version and filesystem Aubrey might be using.

I'm using suse9.3. The filesystem is EXT3.
I think I forgot one thing last night. When I changed the file, I
compiled the package to verify my modification. It should be the
reason. But should it really affect the result of "git diff"?

Thanks,
-Aubrey

Re: Quick question: how to generate a patch?

[Linus Torvalds]

On Tue, 28 Feb 2006, Aubrey wrote:
> 
> I'm using suse9.3. The filesystem is EXT3.

Ok, something else is going on. There's no way ext3 can get confused about 
times that I can see.

> I think I forgot one thing last night. When I changed the file, I
> compiled the package to verify my modification. It should be the
> reason. But should it really affect the result of "git diff"?

Nope. Something else is happening.

If you can re-create this at will, it would be interesting to see _what_ 
makes git think you've modified a file. A small mod to "read-cache.c" like 
the appended patch should give you (very very verbose) output that could 
help us figure this out.

		Linus

----
diff --git a/read-cache.c b/read-cache.c
index f97f92d..4946163 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -183,6 +183,8 @@ int ce_match_stat(struct cache_entry *ce
 	    index_file_timestamp <= ntohl(ce->ce_mtime.sec))
 		changed |= ce_modified_check_fs(ce, st);
 
+if (changed) error("changed: 0x%x %s", changed, ce->name);
+
 	return changed;
 }
 

Re: Quick question: how to generate a patch?

[Aubrey]

> If you can re-create this at will, it would be interesting to see _what_
> makes git think you've modified a file. A small mod to "read-cache.c" like
> the appended patch should give you (very very verbose) output that could
> help us figure this out.
Oops, It's my fault. My mistake is that copy the clone git directory
to another directory for backup. And work on another directory. Sorry
for my incaution.

-Aubrey

Re: Quick question: how to generate a patch?

[Linus Torvalds]

On Tue, 28 Feb 2006, Aubrey wrote:
> 
> =================================================================
> 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.

> >         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