How do we import patches from non-git sources?

How do we import patches from non-git sources?

[Marc Singer]

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.

Re: How do we import patches from non-git sources?

[Johannes Schindelin]

Hi,

On Thu, 24 May 2007, Marc Singer wrote:

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

What author should git-am assume?

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

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

Ciao,
Dscho

Re: How do we import patches from non-git sources?

[Yann Dirson]

On Thu, May 24, 2007 at 07:30:10AM -0700, Marc Singer wrote:
> 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.

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,
-- 
Yann.

Re: How do we import patches from non-git sources?

[Jakub Narebski]

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

Yann Dirson 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/.

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?

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: How do we import patches from non-git sources?

[Linus Torvalds]

On Thu, 24 May 2007, Marc Singer wrote:
> 
> 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.

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

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

[Marc Singer]

On Thu, 2007-05-24 at 07:30 -0700, Marc Singer wrote:
> 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.

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.

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

[J. Bruce Fields]

On Wed, Jun 06, 2007 at 10:37:34AM -0700, Marc Singer wrote:
> On Thu, 2007-05-24 at 07:30 -0700, Marc Singer wrote:
> > 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.
> 
> 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.

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.

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

[Marc Singer]

On Wed, 2007-06-06 at 13:54 -0400, J. Bruce Fields 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.
> 

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.

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

[J. Bruce Fields]

On Tue, Jun 12, 2007 at 09:27:33AM -0700, Marc Singer wrote:
> On Wed, 2007-06-06 at 13:54 -0400, J. Bruce Fields 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.
> > 
> 
> 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.

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.)

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

[Marc Singer]

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:
> > 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.

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

[Matthieu Moy]

Marc Singer <elf@synapse.com> writes:

> On Thu, 2007-05-24 at 07:30 -0700, Marc Singer wrote:
>> 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.

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

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

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.

-- 
Matthieu

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

[Jon Loeliger]

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

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

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

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

[Marc Singer]

On Wed, 2007-06-06 at 13:18 -0500, Jon Loeliger wrote:
> On Wed, 2007-06-06 at 12:58, Matthieu Moy wrote:
> 
> > Cogito is more or less depreceted now. You should probably use git
> > itself.
> 
> 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.

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

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

[Matthieu Moy]

Marc Singer <elf@synapse.com> writes:

> On Wed, 2007-06-06 at 13:18 -0500, Jon Loeliger wrote:
>> On Wed, 2007-06-06 at 12:58, Matthieu Moy wrote:
>> 
>> > Cogito is more or less depreceted now. You should probably use git
>> > itself.
>> 
>> 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.
>
> It's also users who are *just* getting their feet wet in the git pool.

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" ...

-- 
Matthieu