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

From: Marc Singer <elf@synapse.com>
Date: Jun 14, 2007, 01:45 UTC
Message-ID: <1181785504.4102.7.camel@zealous.synapsedev.com>
In-Reply-To: <20070612181313.GB26767@fieldses.org>

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

Show 38 quoted lines

> On Tue, Jun 12, 2007 at 09:27:33AM -0700, Marc Singer wrote:
> > 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 <someone@example.com>
> 	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.