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

From: Alex Bennee <kernel-hacker@bennee.com>
Date: Apr 11, 2007, 11:37 UTC
Message-ID: <1176291474.11130.12.camel@okra.transitives.com>
In-Reply-To: <Pine.LNX.4.64.0704040744160.6730@woody.linux-foundation.org>

On Wed, 2007-04-04 at 08:12 -0700, Linus Torvalds wrote:

Show 11 quoted lines

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

Unfortunately they are all smushed together :-(

<snip>

> 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

Yeah I've tried using the rebase approach (which I in fact use a lot when re-baseing my work anyway without losing my micro commit history). The one fly in the ointment is the branch result at the end contains no changes so I have no historical record of what I did while creating the change.

I assume the commit objects are still in git somewhere but I'm not sure how to get at it. What I would like to ask git is "what did my git-log look like when 'mybranch' was based off master at A instead of B after O rebased?"

For the time being I tend to verify my work has got in by generating a master..branch diff and loading it into emacs patch-mode and testing each hunk has applied ok. I'm still deciding if I should bite the bullet and write some more elisp to make it a one button operation or use a bit of perl with git.

-- 
Alex, homepage: http://www.bennee.com/~alex/
"The most difficult thing in the world is to know how to do a thing and
to watch someone else do it wrong without comment." -- Theodore H. White