Re: Let me ask again: How do we import patches from non-git sources?

On Tue, 2007-06-12 at 14:13 -0400, J. Bruce Fields wrote:

On Tue, Jun 12, 2007 at 09:27:33AM -0700, Marc Singer wrote:

quoted

git-am complains that it cannot find an email address, but raw patches
seldom have these.  So, either we could use another command, or it would
be handy if we could supply the email address to git-am (or some other
data it needs so that it can split the patch.)  I suppose the mistaken
assumption is that the patch source in an email instead of already being
a nice clean patch.

I think it's intentional.  You need some standard format git-am can use
to split out the patches and find the comments and the authorship
information (for the Author: field on the commit), so why not just use
something like mbox?

And it could provide some fallback for the "Author:" information in the
case where it didn't find that, but we wouldn't want that to be the
default if it meant risking silently losing authorship information.  I
suppose an "--author" option to git-am might be convenient sometimes.

But personally I always just add those headers by hand (or with a
script).  It's not that hard; I the minimum required is just three
lines, I think:

	From git-owner@vger.kernel.org Tue jun 12 11:43:40 2007
	From: someone [off-list ref]
	Subject: [PATCH] do something
	
	Do something complicated.
	
	---
	
	diff a/foo b/foo
	...

And often I need different authors on different patches anyway, so
git-am --author wouldn't help.

Of course if you've just got one patch to import, you can git-apply and
then commit.

Thanks for the response.

I found that a deeper look into git-apply gives me a way to import
foreign patches.  I still have to do some index management by hand, but
it is much better than the alternative.

Your suggestion, while clearly effective, seems cumbersome.  I suppose
it may be worthwhile including a command that converts a foreign patch
into something that git better understands.  That would leave out this
sort of complexity from the git-am program.  In fact, I can imaging a
tool that lets the user fill in any pieces that aren't already present.

Honestly, it may just be that I'm still below the knee on the learning
curve for git.

Cheers.