From: Marc Singer <hidden> Date: 2016-06-15 22:43:12
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.
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:43:12
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
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.
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
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
From: Marc Singer <hidden> Date: 2016-06-15 22:43:14
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.
From: J. Bruce Fields <hidden> Date: 2016-06-15 22:43:14
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:
quoted
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.
From: Marc Singer <hidden> Date: 2016-06-15 22:43:15
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.
From: J. Bruce Fields <hidden> Date: 2016-06-15 22:43:15
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:
quoted
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 [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.
--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.)
From: Marc Singer <hidden> Date: 2016-06-15 22:43:16
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.