From: Greg KH <gregkh@suse.de>
To: Mark Einon <mark.einon@gmail.com>
Cc: Greg KH <greg@kroah.com>,
devel@driverdev.osuosl.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 01/26] staging: et131x: Put all .c files into one big file
Date: Wed, 19 Oct 2011 15:28:21 -0700 [thread overview]
Message-ID: <20111019222821.GB31179@suse.de> (raw)
In-Reply-To: <CANK3SE2AEKhw8zSXn3jtGggYh8+SS1mX7Kaue6+vU+B5VjAxWg@mail.gmail.com>
On Wed, Oct 19, 2011 at 10:28:24PM +0100, Mark Einon wrote:
> On 19 October 2011 21:41, Greg KH <greg@kroah.com> wrote:
> > On Tue, Oct 18, 2011 at 05:07:34PM +0100, Mark Einon wrote:
> >> Created one big .c file for the driver, moving the contents of all
> >> driver .c files into it.
> >>
> >> Signed-off-by: Mark Einon <mark.einon@gmail.com>
> >
> > Something is wrong here, when I try to apply this patch with git, I get
> > the following errors:
> [...]
> >
> > Care to resend it with the file actually deleted? How are you
> > generating this patch?
> >
> > And, when you resend the series, don't put the [RESEND] in the subject,
> > I had to edit that out in order to apply them properly (which turned out
> > to be a waste of time due to this patch not applying...)
>
> Apologies Greg, I didn't mean to waste your time.
>
> I've used this command to generate the patch, in order not to include
> the entire file contents that have been deleted:
>
> git format-patch -D <to-list> <patches>
I use:
git format-patch -k -M
If you read the man page for git format-patch, you will see why "-D"
does not work at all for this, and this is why I can't apply these
patches, you are giving me something that is _known_ to not apply:
-D, --irreversible-delete
Omit the preimage for deletes, i.e. print only the header but
not the diff between the preimage and /dev/null. The
resulting patch is not meant to be applied with patch nor git
apply; this is solely for people who want to just concentrate
on reviewing the text after the change. In addition, the
output obviously lack enough information to apply such a
patch in reverse, even manually, hence the name of the
option.
> I also assumed RESEND was commonly used for the purpose of resending
> patches. Is this not the case?
Yes, but you did it this way:
[RESEND][PATCH 02/XX]
and git will just strip off the first [] chunk when applying it. So
unless I wanted the [PATCH...] portion in the changelog, I had to delete
it by hand.
You can do:
[RESEND PATCH 03/XX]
and all would be almost ok, but when I sort the emails, it would break
order.
So best is:
[PATCH 03/XX RESEND]
if you really need the RESEND comment. Personally, I would only do that
in the [00/XX] patch as that's what counts here. You aren't resending
because I ignored them, but because there was a problem with them, so
you know I didn't apply those original ones.
hope this helps,
greg k-h
next prev parent reply other threads:[~2011-10-19 22:31 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-18 16:07 [PATCH 00/26] Mostly resending patches Mark Einon
2011-10-18 16:07 ` [RESEND][PATCH 01/26] staging: et131x: Put all .c files into one big file Mark Einon
2011-10-19 20:41 ` [PATCH " Greg KH
2011-10-19 21:28 ` Mark Einon
2011-10-19 22:28 ` Greg KH [this message]
2011-10-18 16:07 ` [RESEND][PATCH 02/26] staging: et131x: Move function declarations from et131x.h to et131x.c Mark Einon
2011-10-18 16:07 ` [RESEND][PATCH 03/26] staging: et131x: Move non-register defines " Mark Einon
2011-10-18 16:07 ` [RESEND][PATCH 04/26] staging: et131x: move et1310_address_map.h contents into et131x.h Mark Einon
2011-10-18 16:07 ` [RESEND][PATCH 05/26] staging: et131x: move et1310_phy.h " Mark Einon
2011-10-18 16:07 ` [RESEND][PATCH 06/26] staging: et131x: move et131x_adapter.h contents into et131x.c Mark Einon
2011-10-18 16:07 ` [RESEND][PATCH 07/26] staging: et131x: move et131x_defs.h " Mark Einon
2011-10-18 16:07 ` [RESEND][PATCH 08/26] staging: et131x: move et1310_rx.h " Mark Einon
2011-10-18 16:07 ` [RESEND][PATCH 09/26] staging: et131x: move et1310_tx.h " Mark Einon
2011-10-18 16:07 ` [RESEND][PATCH 10/26] staging: et131x: Update TODO list - remove 'put driver into single file' Mark Einon
2011-10-18 16:07 ` [RESEND][PATCH 11/26] staging: et131x: Moving two extern inline functions to .c file Mark Einon
2011-10-18 16:07 ` [RESEND][PATCH 12/26] staging: et131x: Make rx_ring.fbr{0,1} share a common structure Mark Einon
2011-10-18 16:07 ` [RESEND][PATCH 13/26] staging: et131x: Fix issues when USE_FBR0 is not defined Mark Einon
2011-10-18 16:07 ` [RESEND][PATCH 14/26] staging: et131x: use dma_alloc... instead of pci_alloc Mark Einon
2011-10-18 16:07 ` [RESEND][PATCH 15/26] staging: et131x: Match dma_alloc_ calls with dma_free_ calls Mark Einon
2011-10-18 16:07 ` [RESEND][PATCH 16/26] staging: et131x: Tidy up PCI device table definition Mark Einon
2011-10-18 16:07 ` [RESEND][PATCH 17/26] staging: et131x: on transmit, stop the queue if the next packet will fail Mark Einon
2011-10-18 16:07 ` [RESEND][PATCH 18/26] staging: et131x: Convert rest of pci memory management to dma api Mark Einon
2011-10-18 16:07 ` [RESEND][PATCH 19/26] staging: et131x: Remove unused defines Mark Einon
2011-10-18 16:07 ` [PATCH 20/26] staging: et131x: Remove unused rx_ring.recv_buffer_pool Mark Einon
2011-10-18 16:07 ` [PATCH 21/26] staging: et131x: Remove redundant et131x_reset_recv() call Mark Einon
2011-10-18 16:07 ` [PATCH 22/26] staging: et131x: Remove call to find pci pm capability Mark Einon
2011-10-18 16:07 ` [PATCH 23/26] staging: et131x: Remove unused rx_ring.recv_packet_pool Mark Einon
2011-10-18 16:07 ` [PATCH 24/26] staging: et131x: Remove some forward declarations Mark Einon
2011-10-18 16:07 ` [PATCH 25/26] staging: et131x: Remove forward declaration of et131x_adapter_setup Mark Einon
2011-10-18 16:07 ` [PATCH 26/26] staging: et131x: Remove more forward declarations Mark Einon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20111019222821.GB31179@suse.de \
--to=gregkh@suse.de \
--cc=devel@driverdev.osuosl.org \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.einon@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome