Re: How can I easily verify my diffs are in parent branch?

[Linus Torvalds <torvalds@linux-foundation.org>]

On Wed, 4 Apr 2007, Alex Bennee wrote:
> 
> This is not the case of looking through the logs for my commit as I'm
> exporting my changes from my tree into the company system through CVS.
> This means all the usual commit tracking benefits are lost.

Yeah, sad.

> So I have a master branch which tracks this master baseline from CVS and
> each release I import a big change set which includes all the fixes that
> went into that baseline.

So all your small diffs get smushed in as part of one *big* change? Or do 
they still exist in the baseline CVS tree as individual commits?

If they still exist in the CVS tree as individual commits, you're slightly 
better off: you can use "git patch-id" to generate a hash of all the 
patches, and compare just the hashes. That allows you to efficiently find 
patches that have been applied *identically* in both trees.

NOTE! "git-patch-id" generates a hash of a patch by ignoring 
 - line numbers
 - whitespace
 - commit comments
so "identical" means just that the patch has to have the exact same 
context and +/- patterns, but it will still be considered identical if 
it's been moved around (perhaps because some other patch added/removed 
code before it) or if the whitespace has been tweaked.

You can then compare the hashes upstream with all the commits *you* cared 
about, and see if they are all there. But as noted, this only works if 
upstream is expected to actually honor patch-boundaries. If you just get a 
single big changeset that contains *all* the changes, doign this obviously 
won't work.

NOTE2! I don't think anybody actually *uses* git-patch-id, and what you 
should do is to use "git cherry" that does this all internally, but it is 
worth understanding *what* git-cherry does.

So to compare all patch-ID's, you can do

	git cherry cvs-upstream my-branch

adn it should look at all the commits that are in *your* branch but not 
upstream, and report their ID's preceded by a "-" if they are upstream, 
and a "+" if they are not.

You can then look at the "+" commits more closely, to see whether maybe 
they actually did get merged, but got changed/fixed in the process, or 
whether they really are missing.

> Is there an invocation of git-diff or another tool that can tell me all
> my diffs are present in the big uber-commit of my master branch baseline
> release?

If git cherry doesn't work for you, you're kind of screwed and have to do 
it manually. Of course, even "manually" can be done with a lot of help 
from git.

For example, one thing you can do, if the number of commits you have is 
fairly small, is to just be on your "my-branch" and then do

	git rebase [--merge] cvs-upstream

which will rebase your "my-branch" onto the CVS upstream thing. It will 
automatically discard any patches that get merged away (which effectively 
means that they were already there). The end result will be that your 
branch will now either be identical to "cvs-upstream" (if everything was 
already there) or will contain the commits that weren't there on top of 
the new cvs-upstream tip.

NOTE NOTE NOTE! The "git rebase" thing sounds perfect, but the fact is, 
quite often you'll end up having to help it do its work. It really 
defaults to just trying to apply the patches (ie without "--merge" it's 
literally just a fancy

	git-format-patch | git am

pipeline).

So "git rebase" may well be the right thing for you, but quite frankly, 
it's more likely to work well for simple cases (with no real conflicts 
with anybody elses work in the same areas) than for anything complicated.

For complicated stuff, you'll be on your own. "git diff pathname" etc..

		Linus