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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.