mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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

  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