How do we import patches from non-git sources?

It looks like it reduces to something very simple.

Git patches, as generated by git-format-patch, have a header with an email address.

Cogito patches, as generated by cg-mkpatch, have no email address in the header.

git-am doesn't like the cogito patches.

Is there a way to import patches that did not come from git? Remember that we'd like to include the functionality of git-am that adds new files to the index.

Cheers.

Hi,

On Thu, 24 May 2007, Marc Singer wrote:

What author should git-am assume?

You can always use git-apply to apply patches. You have to commit them yourself, though.

Ciao, Dscho

On Thu, May 24, 2007 at 07:30:10AM -0700, Marc Singer wrote:

I have written a patch-application tool as part of the (otherwise stalled) ArcheoloGIT project, clonable from http://ydirson.free.fr/soft/git/argit.git/.

Side note: it could make sense to finalize this script and integrate it in git proper. Opinions ?

Although the command-line interface would probably benefit from an overhaul, it is fully functionning, notably supporting:

- application of several patches in one row
- application of non-incremental patches - eg. the 2.4.19rmk2 patch
applies to plain 2.4.19, not to 2.4.19rmk1

| $ ../argit/ag-import-patch --help
| Usage: ag-import-patch ( [-v] [-n] [-b BASE|-i] [-N NAME] [-p PARENT]... [-t TAG] PATCH )*
| 
| Import a revision in a GIT history from a patch.
| Part of the ArcheoloGIT toolkit.
| Copyright (c) Yann Dirson, 2005
| Distributed under version 2 of the GNU GPL.

Since it lacks doc, here is it:

-i		- process subsequent paches as incremental (the default)
-b BASE		- process subsequent paches as applying to commit BASE
-N NAME 	- use given NAME instead of patch filename for generating
		  commit message (useful for /dev/stdin import)
-t TAG		- tag after import
-p PARENT	- add PARENT to the parents

eg:

$ git checkout v2.4.19
$ ag-import-patch -b v2.4.19 \
	-p v2.4.18rmk6 -t v2.4.19rmk1 patch-2.4.19rmk1.diff \
	-t v2.4.19rmk2 patch-2.4.19rmk2.diff 

Hope this helps,

[Cc: Yann Dirson <ydirson@altern.org>, git@vger.kernel.org]

Yann Dirson wrote:

By the way, have you considered adding a mirror of this repository to http://repo.or.cz ? This way you would have gitweb interface, and other protocols support.

Could you edit description file, and add README if it does not exists?

On Thu, 24 May 2007, Marc Singer wrote:

The normal thing to do is

	git apply --index <patchfile>

which will apply a patch _and_ update the index, so that you can then just do a simple

	git commit -m "my message goes here" --author "the author goes here"

to create the commit, new (or deleted) files and all.

Of course, the reason the "normal" patch format is an email, and not just a bare patch, is that an email contains so much more: it contains not just the patch, but the authorship information and the commit message.

So basically:
 - no, you _cannot_ just "commit" a patch, since a patch on its own 
   doesn't contain the required information to be a real commit.

 - but yes, you can obviously _apply_ a patch, and then commit it once you 
   add the proper information, but that does require more information than 
   just the patch itself includes.

So hopefully that clarified things.

		Linus

On Thu, 2007-05-24 at 07:30 -0700, Marc Singer wrote:

I have patches from another source as well and I'd like to be able to import them even though these aren't from git.

On Wed, Jun 06, 2007 at 10:37:34AM -0700, Marc Singer wrote:

Based on my notes from the last time I needed to feed a bunch of non-mbox, non-git-produced patches into git-am, the hard part was figuring out how it split a file into separate messages; my notes say:

	"Finds lines begining with "From " and ending with "hh:mm:ss
	yyyy".  See builtin-mailsplit code for more details."

Other than that, I think it just needs and From: and Subject: lines to get author and first-line of the commit. the git-am man page has some documentation of this. It could probably use more.

--b.

On Wed, 2007-06-06 at 13:54 -0400, J. Bruce Fields wrote:

I'm not sure that I understand your response. 

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.

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

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.

--b.

(PS: Standard practice around here is to leave people on the To: and/or
Cc: lines when you reply, and for me at least that'd be easier.)

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

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.

Marc Singer <elf@synapse.com> writes:

Cogito is more or less depreceted now. You should probably use git itself.

You cannot "import" them, because they do not contain the necessary information (commit message and email adress). But you can "apply" them, and then commit manually. Use git-patch (even just "patch" could do) to apply the patch, and commit as usual.

On Wed, 2007-06-06 at 12:58, Matthieu Moy wrote:

Hmm. We should then likely try to encourage kernel.org and denx.de folks to advertise cloning their published repos with git rather than cogito now.

jdl

On Wed, 2007-06-06 at 13:18 -0500, Jon Loeliger wrote:

It's also users who are *just* getting their feet wet in the git pool.

Marc Singer <elf@synapse.com> writes:

Yes, and cogito definitely _used_ to be a very good thing for them. But today, starting with cogito instead of git is not really easier for a beginner: OK, the program is a bit simpler to use, but some commands are missing, so you'll sometimes have to type "git" and sometimes "cogito" (the cogito tutorial was actually using a few git commands). Then, the user comes on the mailing list and asks something, he will be answered in terms of git commands 95% of the times, ...

For that reasons, the maintainer of cogito said some time ago that he was probably going to stop working on cogito. Maybe I missed something in the meantime, but I don't think anyone volunteered to continue with cogito. So, encourraging people to use cogito is a bit like "hey, try this, but once you've finished learning it, you'll have to forget it and migrate" ...